| |||||||||||||
Expanding seccompExpanding seccompPosted May 12, 2011 6:41 UTC (Thu) by cras (guest, #7000)In reply to: Expanding seccomp by TomMD Parent article: Expanding seccomp
The problems I see with writing my own policy are (assuming my SELinux understanding is correct):
* They couldn't automatically be used by anyone. Distros might pick them up for their own packages and admins might manually copy the file somewhere to use it (maybe replace the distro's own), but there is no good way to start using the policy automatically with just "make install".
* People seem to disable SELinux often, because it breaks some software. Having a policy isn't useful if the whole SELinux is disabled. It would be nice if SELinux had also a new mode: Globally disabled, but enabled for apps that explicitly enable it for themselves.
* The policies can't be dynamic. I might want slightly different policies depending on what my config file contains.
(Log in to post comments)
Expanding seccomp Posted May 12, 2011 18:20 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
as I understand it, it's not possible to write a SELinux policy for just one application, due to the simple fact that SELinux policies work on the basis of each file having a single tag.
so all policies that have to touch a file (or directory) have to agree on what tag to use for that file or directory.
this makes it impossible to ship a policy for your software, as you have to coordinate the tags with everything else on the system.
this is one of the things that I see as making AppArmor so much better in the real world. since it doesn't depend on global tags, but instead lists what files are allowed, the AA policy for a particular app really can be independent of the policy for all other apps. So it could be provided by the software developer.
Expanding seccomp Posted May 13, 2011 0:06 UTC (Fri) by cras (guest, #7000) [Link]
I'm not too interested in the "tag" vs "path" debate. For my use case (IMAP server) I don't think it makes any real difference. Many people use virtual users, where all users' mails are stored using
the same UNIX UID. For extra security it is possible to chroot into a user's mail directory though. So I'd primarily want to avoid any potential ways to get around that chroot into other users' mails, by preventing syscalls that just aren't necessary.
|
|||||||||||||