On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:

On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:

quoted

On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:

quoted

On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:

quoted

Yup, I see that once you accept the notion that it is OK for a
file to be misslabeled for a bit and that having a fixxerupperd
is sufficient it all falls out.

My point is that there is a segment of the security community
that had not found this acceptable, even under the conditions
outlined. If it meets your needs, I say run with it.

If that segment feels that way, then I imagine AA would not meet their
requirements today due to file handles and other ways of passing around
open files, right?

So, would SELinux today (without this AA-like daemon) fit the
requirements of this segment?

Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
using the features of SELinux where appropriate.

Great, but is there the requirement in the CC stuff such that this type
of "delayed re-label" that an AA-like daemon would need to do cause that
model to not be able to be certified like your SELinux implementation
is?

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.

2) Whether this would pass certification depends on a lot of factors
(like the specific requirements - CC is just a process not a single set
of requirements). I don't know enough to really guess.

More to the point, though, the requirements in those documents are
outdated at best. I don't think it is worth worrying over.

As I'm guessing the default "label" for things like this already work
properly for SELinux, I figure we should be safe, but I don't know those
requirements at all.

Probably not - you would likely want it to be a label that can't be read
or written by anything, only relabeled by the daemon.

Karl