| |||||||||||||
Expanding seccompExpanding seccompPosted May 12, 2011 18:20 UTC (Thu) by dlang (✭ supporter ✭, #313)In reply to: Expanding seccomp by cras Parent article: Expanding seccomp
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.
(Log in to post comments)
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.
|
|||||||||||||