Should we get rid of the old chroot jails and trust to apparmor? They are both basically trying to avoid unforseen and unwanted access to the filesystem. eg: The default profile for postfix fails because it doesn't bestow "chroot" privileges to smtpd. Once bestowed, there are problems because the chrooted daemon wants to get to /default/some-file and doesn't know it's actually talking about /var/spool/postfix/default Neither does apparmor 8^( Is the best practise way to tell postfix NOT to chroot? There are ways of breaking out of chroot jails aren't there? Has apparmor been coded to secure the known techniques? It's more versatile, is it more secure? How much of a performance hit? Thanks for any discussion of this, michaelj PS: RTFM replies welcome; as long as they give links to the FM. -- Michael James michael.james@csiro.au System Administrator voice: 02 6246 5040 CSIRO Bioinformatics Facility fax: 02 6246 5166 No matter how much you pay for software, you always get less than you hoped. Unless you pay nothing, then you get more.
Michael James wrote:
Should we get rid of the old chroot jails and trust to apparmor?
For existing code that is already chrooting itself: it is not worth the bother. AppArmor will work with the chroot'd code, so just let it. For new situations: AppArmor and chroot provide similar security value, but AppArmor confinement is easier, and does not require modifying the software. So I would recommend using AppArmor and not bothering with chrooting.
They are both basically trying to avoid unforseen and unwanted access to the filesystem.
eg: The default profile for postfix fails because it doesn't bestow "chroot" privileges to smtpd. Once bestowed, there are problems because the chrooted daemon wants to get to /default/some-file and doesn't know it's actually talking about /var/spool/postfix/default Neither does apparmor 8^(
Caveat: AppArmor *currently* uses policies that are relative to your chroot jail, so if the application does a chroot to /var/myjail and then opens the file /var/myjail/etc/shadow, then the AA policy will allow /etc/shadow. This is a security risk, in that if the chroot call somehow fails, then you have a policy that permits access to the system's /etc/shadow. We intend to change this so that the policy would explicitly allow /var/myjail/etc/shadow regardless of chroot calls. This will make the policies more secure, but will also require changes in your policies. We apologize for this disruption, and we will announce it clearly when this change comes.
Is the best practise way to tell postfix NOT to chroot?
Given the above issue, you are better to use AppArmor without chroot than with chroot.
There are ways of breaking out of chroot jails aren't there?
Yes, there are. If you have a hard link or a symlink leading out of the jail, or the process holds an open file descriptor pointing out of the jail, then it may be able to escape.
Has apparmor been coded to secure the known techniques?
AppArmor will not prevent the process from escaping the chroot jail, but will prevent it from escaping the AppArmor profile.
It's more versatile, is it more secure?
Yes, AA is more secure than a chroot jail.
How much of a performance hit?
AA overhead is low, usually in the range of 0-5%, mostly around 2%. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unaticipated problem Hacker: one who is adroit at pounding round pegs into square holes
participants (2)
-
Crispin Cowan
-
Michael James