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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
