On Thu, 2005-10-06 at 11:44 +0100, David Howells wrote: > James Morris <[EMAIL PROTECTED]> wrote: > > > One thing I'm concerned at, which I suspect you may be, is that if we > > include key objects in LSPP, then we may need to go further than just > > "access to objects" and start looking at the semantics of the keys, > > effectively implementing crypto policy. e.g. it may not just be enough to > > have labels assigned to keys, but to have those labels reflect the content > > of the keys (e.g. "high_assurance_cipher_t"). > > My main idea how to use key labelling is to label keys intended for specific > targets. For instance, with AFS there is a collection of standard utilities > which use AFS keys to access the various AFS servers. These run in userspace > and, reasonably, want to be able to read your AFS keys. However, you may not > want it to be possible to use such as keyctl, for example, to just dump the > key contents. > > So what you'd do is label your AFS keys as only being able to be read by AFS > services, such as the AFS kernel module or the AFS utility programs. > > > In any case, if there are no significant in-tree users of the key > > subsystem, then I'm not sure we need to include this subsystem in the LSPP > > evaluation. > > There are no in-kernel users of this facility yet. > > > David: can you explain who is using this code > > Keys are being looked at for use with OpenAFS, NFSv4, eCryptFS, Reiser4, > Kerberos and SSH that I know of.
Hi, Can you provide an update on who is actually using the kernel keyring support at this time, with particular focus on users that are likely to be included/supported for RHEL? I ask because the question of whether we need to implement SELinux controls for kernel keyrings for LSPP certification has arisen again. We can easily implement a naive set of controls within the current set of hooks, but whether or not that will immediately break the current users of this functionality in a multi-context environment is unclear. We also have to assess whether the current hook set is adequate, and whether your current user-centric model needs to be extended to support per-context keyrings and keys. -- Stephen Smalley National Security Agency -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
