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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
