linux-kernel - Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200706211754.19708.agruen@suse.de>
Date:	Thu, 21 Jun 2007 17:54:19 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Stephen Smalley <sds@...ho.nsa.gov>
Cc:	Karl MacMillan <kmacmill@...hat.com>, Greg KH <greg@...ah.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Crispin Cowan <crispin@...ell.com>,
	Pavel Machek <pavel@....cz>, 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

On Monday 18 June 2007 15:33, Stephen Smalley wrote:
> On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> > There are two things:
> >
> > 1) relabeling (non-tranquility) is very problematic in general because
> > revocation is hard (and non-solved in Linux). So you would have to
> > address concerns about that.
>
> I think we need to distinguish between relying on restorecond-like
> mechanisms for the security of SELinux vs. relying on them for emulating
> pathname-based security.  The former would be a problem.  The latter is
> no worse than pathname-based security already, because pathname-based
> security is inherently ambiguous and non-tranquil, and revocation isn't
> addressed fully in AA either.

Emulation using lazy relabeling introduces a window where the files have the 
wrong label. In those windows, the pathname based policy is being violated, 
and unintended side effects are suddenly possible. This includes granting of 
access to files that applications should no longer have access to according 
to the pathname based policy, which would be similar to what happens when a 
process keeps an open file handle right now. But it also includes denial of 
access to files that applications should have access to, and this might cause 
those applications to fail. So this is where relabeling from user space is 
much worse.

The only way to get rid of the denial of service problem would be to make the 
rename and relabel an atomic operation. The time this can take is huge 
though, so that's not acceptable.

Another, less catastrophic problem is that rename has always been relatively 
fast and inexpensive, and I'm sure plenty of applications rely on this 
performance characteristic. Making rename a very expensive operation in at 
least some cases (which are more than theoretical) would hurt those 
applications, and nothing much could be done about it.

Adding better new-file mechanisms to SELinux probably is a good idea, and it 
would weaken the SELinux seurity model for all I can tell. It doesn't address 
the relabeling problem though.

Andreas
-
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/