| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20070615200623.GA2616@elf.ucw.cz> Date: Fri, 15 Jun 2007 22:06:23 +0200 From: Pavel Machek <pavel@....cz> To: Greg KH <greg@...ah.com> Cc: Crispin Cowan <crispin@...ell.com>, Andreas Gruenbacher <agruen@...e.de>, Stephen Smalley <sds@...ho.nsa.gov>, jjohansen@...e.de, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching Hi! And before you scream "races", take a look. It does not actually add them: > > > I agree that the in-kernel implementation could use different abstractions > > > than user-space, provided that the underlying implementation details can be > > > hidden well enough. The key phrase here is "if possible", and in fact "if > > > possible" is much too strong: very many things in software are possible, > > > including user-space drives and a stable kernel module ABI. Some things make > > > sense; others are genuinely bad ideas while still possible. > > > > > In particular, to layer AppArmor on top of SELinux, the following > > problems must be addressed: > > > > * New files: when a file is created, it is labeled according to the > > type of the creating process and the type of the parent directory. > > Applications can also use libselinux to use application logic to > > relabel the file, but that is not 'mandatory' policy, and fails in > > cases like cp and mv. AppArmor lets you create a policy that e..g > > says "/home/*/.plan r" to permit fingerd to read everyone's .plan > > file, should it ever exist, and you cannot emulate that with SELinux. > > A daemon using inotify can "instantly"[1] detect this and label the file > properly if it shows up. Or just create the files with restrictive labels by default. That way you "fail closed". > > * Renamed Files: Renaming a file changes the policy with respect to > > that file in AA. To emulate this in SELinux, you would have to > > have a way to instantly re-label the file upon rename. > > Same daemon can do the re-label. ...and no, race there is not important. Attacker may have opened the file under old name and is keeping open file descriptor. So this does not add a new race relative to AA. > > * Renamed Directory trees: The above problem is compounded with > > directory trees. Changing the name at the top of a large, bushy > > tree can require instant relabeling of millions of files. > > Same daemon can do this. And yes, it might take a ammount of time, but > the times that this happens in "real-life" on a "production" server is > quite small, if at all. And now, if you move a tree, there will be old labels for a while. But this does not matter, because attacker could be keeping file descriptors. Only case where attacker _can't_ be keeping file descriptors is newly created files in recently moved tree. But as you already create files with restrictive permissions, that's okay. Yes, you may get some -EPERM during the tree move, but AA has that problem already, see that "when madly moving trees we sometimes construct path file never ever had". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists