On Mon, 2006-04-03 at 03:27 -0500, Robert Nichols wrote: > Craig White wrote: > > On Mon, 2006-04-03 at 09:21 +0200, Eugen Leitl wrote: > > > >>On Sun, Apr 02, 2006 at 08:08:42PM -0300, Jacques B. wrote: > > > > > >>SELinux has no business running on a user desktop (=kitchensink) > >>if the policy is not well maintained. Things like RSBAC/grsecurity/SELinux+PaX > >>can be useful on a server. > > > > ---- > > if Windows exploits are any indication, it is primarily desktop systems > > which are the target for malware that infects the system for nefarious > > purposes. Why? Because the users are often not knowledgeable, run with > > elevated privileges, travel to web sites that attempt every conceivable > > exploit in a plethora of scripting languages, etc. > > > > The policy updates from Fedora have been frequent and are automatically > > installed/applied > > True, and they might even be workable on a system that is set up > with 100% standard file system structure and users whose interaction > with the OS is limited to clicking on icons. Add a separate > filesystem for large downloaded files or have a user that uses the > (gasp!) command line to do bizarre things like redirect the output > from ping onto a file in his home directory and SELinux starts > blocking you at every turn unless you can spend the time to become > an SELinux guru and figure out what needs to be tweaked in the > policy or attributes to fix things _this_ time, and try to guess > how badly that change will break when tomorrow's policy update gets > installed. ---- I am no SELinux guru - I would reserve that distinction for someone like Paul Howarth. I have noticed though that even with my limited skill sets, SELinux has been very manageable and the alterations to targeted/policy/sources has been easily managed on FC-3, FC-4 and RHEL-4. I haven't played with FC-5 but I know there are new tools. Likewise, changing file contexts with chcon have been relatively simple. ---- > > I'm sure SELinux can be great on a server where a well defined set > of operations are performed over and over, but trying to write a > security policy that can accommodate the huge variety of things > that can be legitimately expected to be done on a desktop system > looks like a task doomed to failure. ---- I don't see that - I see people conceding defeat without trying. Again, I think the biggest obstacle is the use of language tokens that make it appear to be complicated where if it were natural language, far fewer people would be freaked out. In reality, it's not a server/desktop thing. It's only a matter of whether said user is willing to spend the time/energy necessary to understand at the very least, how to stop SELinux blocks from happening. It looks like rocket science, it's not rocket science. Craig
