Snet and the LSM API

Posted Jan 29, 2009 4:12 UTC (Thu) by pragmatine (guest, #39557)
Parent article: Snet and the LSM API

Interestingly a few years ago I started work on a more general framework to allow userspace to allow / deny different security decisions using the LSM API called PULSE: A Pluggable User-space Linux Security Environment - and to demo the framework I implemented a basic personal firewall - so this looks quite similar to that. When doing this work I also identified similar concerns to those raised about snet (ie. training users to just click allow) - more info is available in the following paper: http://crpit.com/abstracts/CRPITV81Murray.html - source is online at sourceforge: http://sourceforge.net/projects/pulse-lsm/

Unfortunately I haven't been able work on this since then so its a bit outdated but some of the ideas could be useful for the snet developer and for others developing custom LSM modules.

Incidentally, I believe the ability to stack LSM modules would greatly improve their adoption, this way you could have a number of modules which each do one thing well - ie. AppArmor for file access control and perhaps snet for network access control, rather than trying to have something like SELinux for everything.

to post comments

Snet and the LSM API

Posted Jan 29, 2009 4:18 UTC (Thu) by pragmatine (guest, #39557) [Link]

One more comment about PULSE - the thing I want to emphasise is this is a general framework for allowing normal users to exercise mandatory access controls over their own processes, and so it is much more flexible than all the existing frameworks (SELinux, AppArmor, SMACK etc) which only allow the system administrator to define access controls for ALL users. PULSE allows different users to give their applications different permissions, since it is user-specific, and user-centric. It is also highly dynamic (allowing decisions to be made on the fly and also revoked on the fly), compared to SELinux etc which are based upon static security policies - hence it is much more oriented to desktop usage compared to SELinux etc which are more suited to servers which perform well-defined, static operations.