From: "Peter Werner" <[EMAIL PROTECTED]> > hi > > extra acl patches and stuff are nice things but there are some big problems > with actually integrating them into a system. there are lots of factors, it > takes a long time to install and configure things properly, and being human > people make mistakes (perhaps completely invalidating the setup), if you > have the time take a look at how many configuration files selinux has > (lots). secondly, a flawed implementation can introduce new security > problems, most of the core linux stuff has been pretty well audited, why add > heaps more complexity? most importantly (imho) is all existing software has > been designed with the > current unix security model assumed. if you change that assumption you have > to at the very least go through and check it will play nicely with the new > model. optimally you would go through and change everything to take > advantage > of the new model. otherwise you introduce new security problems, ala the > sendmail capability problem a while back.
Well, the reason for implementing a system like RSBAC is not system-security (on the level of the operating system) alone. The other important aspect that RSBAC could give you is privacy. In the normal linux-security model (unix) the administrator/root can access all files (user/OS-related) in the system. You don't always want that. IMHO, it fits perfectly in the current model of sme (admin/users/groups) It could be a selling point: as an reseller (or administrator) : you can assure your client that his/her data is kept private from your (prying) eyes :) Again, the question was: has anybody tried to implement it. I just would love to hear some experiences. Doesn't necessarily have to be on essg/sme. > this stuff seems a bit overkill'ish for sme in my opinion, one thing that Well, that depends on where you'd want to use sme for. Regard, Bart Koppers OpenCare -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
