On Wed, 25 May 2005 13:20:06 EDT, Colin Walters said: > Why would your security policy specify implementation details like > chroot? A more sensible security policy would be something like "BIND > cannot affect the PostgreSQL server". You weren't paying attention - I *granted* it was a silly rule. But every once in a while, somebody screws up and lets the auditors get access to some 8x11 color glossy, and once that happens there's no shifting it. ;) The point is that SELinux is able to do a very good job at controlling access via a model where everything is *labelled*. It however does a *very* poor job of making decisions based on *state* - are we chrooted? Are we this, are we that? > With SELinux you can analyze all > the information flow from named_t to postgresql_t. With a chroot you > have no such guarantees. Your security goals should drive your > implementation choices, not the other way around. A good while ago, I was discussing an LSM based on the OpenWall patches, and the reasonable security goal of "don't follow a possibly hostile symlink". In order to actually do it, you'd basically have to use the 'strict' policy, give each user their own $USER_u - and then you could add the 5-6 lines of policy that did the same as a 15-line LSM exit. Except the SELinux one will have chewed up some 20M worth of avc_node slab entries (which makes a noticeable difference if you're trying to secure an older box that only has 128M or 256M installed). No, saying "get newer hardware" isn't an option, unless you're going to pay for upgrading the entire lab full of machines. Also remember that I do *NOT* need "perfect security even in the face of some 0-day nobody's ever seen before". I need to prevent "student A uses 2-decade-old-trick to hose student B". I can't *justify* spending all the resources to do a totally bulletproof setup. I however can't justify not doing anything at all.... And yes, I *KNOW* the Right Answer there is "Use some other LSM that meets the goals needed". The point is that there *DO* exist *real world* security issues that the SELinux model is not all that well suited for.
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 14:33:59 PDT