On Mon, 2014-03-10 at 18:28 +1300, Volker Kuhlmann wrote: > On Mon 10 Mar 2014 12:14:28 NZDT +1300, Kent Fredric wrote: > > > On 10 March 2014 11:41, C. Falconer <[email protected]> wrote: > > > > > Drop a message in the log file, if nothing else. > > > I would imagine if you logged everywhere read access failed due to > > security, you'd have a log file so deep you would quickly run out of > > diskspace. > > I have not used selinux because I get apparmor out of the box, so I > can't speak for selinux. However, apparmor behaves as I described, it > prevents access if the access isn't permitted by one of its apparmor > rules. Failures are logged, they should trigger your alarm (if you have > the system correctly configured). For configuration you put the system > into trial mode, which is the as-shipped state. Here, all accesses > denied by rules are logged and permitted, so you set up your rule base. > > The level of control with apparmor rules puts filesystem rules to shame. > Once you are on a production server you start apparmor during early > boot, after which it can not be disabled. root has no special > privileges. > > This sounds like a sensible system to me, to overcome the historic state > of the *ix permission system, which was primitive when designed and is > not really that adequate today. It's even more true for filesystem > permissions, hence complex (and IMHO barely usable) afterthoughts like > ACLs, which I find frequently unusable because they don't give me things > like "if the file is under this directory, I want permissions XYZ", > especially after being copied there. Perhaps extended attributes and > capabilities go some way towards apparmor/selinux, but obviously not far > enough or server vendors wouldn't have developed apparmor and selinux. > > Perhaps it's just that selinux sucks compared with apparmor...? ;-) > > Volker > Hmm... we're talking production servers here are we? If that's the case, then they will very rarely be generic, and unwanted services are already removed, and there will rarely be users directly accessing the server. They will also be heavily monitored... something else that the out of the box selinux fails to allow - in fact you can't even move a website docroot out of /var/www without a fight.
Personally cannot think of a single use case for "if the file is under this directory, I want permissions XYZ" which can't be delivered by the current MAC/DAC/umask system... well, not one I'd want to see on a production server - KISS is paramount! Use of secondary groups+setgid +(rarely) umask+pam.d changes has done just about everything I need* I personally would ( well, do! ) separate specific functionality by server - be it dedicated or virtual - and certainly do not use software like this who's prime function in practice is to - as Craig so rightly states IMO - get in the way of Administrators. I am closely following the docker project too... Steve *with the exception of locking down production website docroots where I use lock/unlock scripts to facilitate changes. But that's a time-dependent thing really. -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa _______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
