On Wed, 2006-05-17 at 11:50 -0400, Stephen Smalley wrote: > On Tue, 2006-05-16 at 15:30 -0500, George C. Wilson wrote: > > Yes, you're right. David Howells' keyring hooks went in. The LSMs need to > > be > > updated to implement those hooks. I was under the impression that work was > > done. But it wasn't. The ultimate answer is that somebody needs to do that > > for SELinux, which I'd like to think should be a fairly small task. But I > > thought we had a way to restrict keyring operations to admins w/DAC for the > > evaluated configuration, which is why it is marked 90%. If not, we have > > hooks > > to implement. There would be no policy for them in the evaluated > > configuration. > > Implementing a basic set of checks in the current set of hooks would be > straightforward. Whether or not such checks would a) prevent > information flow in violation of policy, and/or b) enable the expected > usage model for the keys to continue to work in the presence of > processes with multiple security contexts running in the same user > session is not at all clear. That's the harder question.
Trimmed cc list as the redhat-lspp list bounced it due to too many recipients (odd). Quick question: What is using the kernel keyring support? OpenAFS? I don't see anything in Linus' tree using it in-kernel at present. So why is it there? Looks like ecryptfs is using it over in -mm. If nothing in the evaluated configuration is using it, can it just be disabled in the evaluated kernel? -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
