On Wednesday, December 08, 2010 10:39:50 am Les Mikesell wrote: > On 12/8/2010 9:21 AM, Lamar Owen wrote: > > Alright, pray tell how I, a desktop Linux user, can, without VM's and without having to switch users, protect my files from a PDF attack through Adobe Reader? > > Don't run software you don't trust. Keep the software you run up to > date. Don't open files you don't trust. That has nothing to do with user-id based security, Les. And you're intelligent enough to know that. You cannot trust any file or software 100%; to trust 100% any file or software over which you don't have 100% control is foolhardy. The OS needs to be able to execute untrusted software in a safe fashion in order to be usable in this day and age, especially with SaaS and cloud computing becoming more and more prevalent. We're not in the 70's or 80's any more; we need working controls that allow untrusted software to be run safely, even if the user running that software is root. Sorry, that's just a simple fact of life in this connected age. Of course, you then need to trust your OS, but the fact that you run the OS is strong prima facie evidence that you trust it at least to a degree (this is of course why I run Linux; I trust it more than the others). > > Or a surf-by web infection (NoScript can help; NoScript is also a pain)? > > Don't visit web sites you don't trust with browsers that auto-execute stuff. Visit Linuxtoday.com and go to one of the linked articles; let your cursor roll over a double-underlined word. What happens? What could happen? What about web caches in between? Or rooted cisco routers sending your traffic to and from a WCCP transparent webcache that poisons the stream, does MITM SSL funniness, or worse. Or a BPG AS hijack such as what was done back in April, that causes your traffic, without your knowledge or awareness, to traverse an autonomous system under potentially nefarious control (can happen, thanks to the nature of BGP)? How do you know for a fact that your packets to and from that trusted website are not filtered, munged, and otherwise changed along the way? Can you trust SSL to not be vulnerable to MITM attacks? You cannot trust any website 100% (no, you cannot trust 100% *any* website that you don't personally have full control of its software, as well as any and all caches/redirectors/accelerators/routers/switches/AS's in between). The only way to be 100% sure is to not visit any websites at all, ever, period. Wouldn't it easier to apply mandatory access controls to the web browser and allow untrusted content to be rendered safely? > >But the desktop security use case often gets short shrift, and thus I raise that banner, being that I have been a desktop Linux user for 13+ years) > > Does the default configuration cover the cases you present? I seriously doubt that it does; I would like to see it cover those cases, even if that means me doing my own legwork and codework. > Or are you > suggesting that every user needs the equivalent of a 4 day/$3K training > course to be able to secure their linux distribution? No; what I'm suggesting is that the experts out there that have the corner cases (and the time and inclination to help) try it, at least in testing, and help out an open source effort, the fruits of which they're enjoying, in the case of CentOS, for free, instead of being time-consuming gadflies. I plan to spend some time over the holidays in some autodidactic exercises on this subject; the cost will be minimal, and I'll be the better admin for it. And I'll have a safer system on which to run untrusted software with less risk. There are many things that need improvement; making a 'this is the way my system runs normally; create a module that won't break when I update things (and define what 'won't break' means)' module builder (for all I know, one may exist already, and audit2allow in conjunction with permissive mode does part of this for you). Not breaking a working system is important to some; failing safe (I'd rather it fail closed than open; YMMV) is also important to others, depending upon the use case of the system. But the developers of the system cannot possibly nor reasonably be expected to know all the corner cases that people seem overly concerned with (any third party app is by definition a corner case relative to the OS as shipped). They have to have bug reports and help in finding these cases. Simply saying 'I fixed it by turning it off, and, no I don't have time to send you a bug report, you just have to guess what went wrong because I'm not turning it back on until you fix your bug' is just unproductive. If you want to disable SELinux, then of course by all means go ahead; the risk is all yours. The problem I and others have with the attitude of then making that the default advice sent to the list is that it doesn't help fix the underlying issues, and since the upstream does in fact ship SELinux on by default it is more useful in the default case to try to help fix the actual problem instead of griping about it being junk. If you prefer to not provide useful information, well, that is of course your right. But that doesn't change my opinion that 'Disable SELinux, do it the Old Unix Way and all will be well' as default advice is useless, and does not help make the default CentOS experience any better.