[redhat-lspp] LSPP/RBACPP requirements v.002

[Stephen Smalley]

On Wed, 2005-09-28 at 13:24 -0400, Steve Grubb wrote:
> I was thinking the xinetd patch was to get services to start in the right 
> context and at the right level.

Yes, that is also my assumption, but it raises some questions, e.g.
- is the context of the peer socket the right context in which to run
the service (at the very least, for the TE type, the answer is no)?
- does xinetd have enough information to compute the right context in
which to ultimately run the service, since it doesn't handle user
authentication itself?
- if xinetd transitions to a context based on the peer socket, and the
service then wants to transition to a context based on the authenticated
user, how do these transitions interact with one another (e.g. can the
latter fail due to the former; should the latter be based off the former
in some way)?
- do you trust the client to supply the context in which to run the
service?
- what happens when the client and server have different context/policy
definitions?

> I think we need a definition of what this consistency check really entails.
> 
> Does it check that all audit rules in /etc/audit.rules is currently loaded, 
> all file permissions & checksums match kind of like tripwire, all MAC rules 
> are currently loaded?

I suspect that this goes beyond what is actually required.

> If so, we need to teach tripwire about extended attributes. I can easily 
> compare audit rules in the file with what's loaded. Not sure if MAC rules can 
> be checked without some programming.

I'm not sure what you had in mind for the audit rules, but I was only
proposing a checksum over the entire binary policy image, computed by
the SELinux module at policy load time and made available for reading
via a selinuxfs node.  Note that such a feature would only let you
compare against a given kernel binary policy file (assuming that we
migrate to policy file regeneration on all local changes), not against
the files actually be managed by the admin (which would be fed into
building that binary policy file).  It also wouldn't give you a real
check on the in-memory policy data structures being used by the SELinux
module at runtime, which are dynamic data structures populated at load
time from the binary policy image.  And of course, none of this deals
with a compromised kernel itself...

-- 
Stephen Smalley
National Security Agency