On Monday, November 29, 2010 12:38:20 pm Les Mikesell wrote:
> [Most thrid party apps qualify as]
> Pretty much anything that needs to write files outside of the home
> directory of the owning user. Certainly anything that uses apache with
> its own data store.
Which is the prime target for SELinux anyway. If it runs in-process in apache you need better protection than the standard UNIX uid:gid.
> > All of the third-party software I run seems to run just fine, as long as the right contexts are applied.
>
> Well, obviously it will work after someone takes the time to make it
> work.
Exactly. Proper information security is becoming more and more critical; educating the executive suite on the need for good information security is a big part; they're obviously going to want justification for the time spent.
If a particular app is so recalcitrant that SELinux needs to be turned off, that's when I'd be doing some drastic things, much like windows lab environments need done. Things like automatic revert to known-good snapshot on the production boxes for all but the data files. Things like isolation in a VM for those apps. Of course, that's also work, and getting SELinux working properly might be less work. Everyone wants less work per project to get more projects done, of course, but cutting corners is still cutting corners and one day it will come back to haunt the corner-cutter.
> Now it is your turn to quantify: How much would you charge to
> teach someone to be able to make those changes and how long would it
> take? This has to include the ability to quickly diagnose and fix any
> problem that might be caused by updates to the application or to the OS
> distribution.
To teach, $50 per hour (if I were available to teach; at the moment I'm full on my work hours). The number of hours would depend upon the complexity of the application; for Scalix, assuming no familiarity with either Scalix or SELinux, eight to sixteen hours (one-two days). Basic stuff wouldn't take more than five to ten hours at most; but I've not done a full workup of an 'SELinux' course, either, and I bet Red Hat has; might even be something they offer, I don't know. Their instructors would likely do a much better job than I, since they teach it more often and probably more rigorous, as I don't really consider myself an expert in SELinux itself; I know enough to get my stuff to work with SELinux in enforcing/targeted mode, that's all. And I can share that experience; I can also share the experience of having been hacked once, and also the experience of multiple layers (including SELinux) preventing a hack (or two).
But training in 'SELinux did this, do that' or 'here's common symptoms of SELinux issues, and here's how to get into permissive mode so you can figure out what's breaking, and here are your triage tools' is a vital part of using SELinux to its potential.
But an ounce of prevention is worth a pound of cure; once an information theft occurs, it cannot be undone.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
