On Sat, 27 Oct 2001, Andi Kleen wrote: > On Sat, Oct 27, 2001 at 03:58:22PM +1000, James Morris wrote: > > > > I was hoping that skb->security could be reassigned as a void pointer > > for use by LSM in 2.5, if LSM is accepted into the kernel. > > void pointer alone without any rules for freeing and reference counting > (e.g. what to do with it on a skb_clone() or a skb_copy()) would not > make too much sense. Getting that right would be probably ugly > (similar to rusty's old abandoned ->cb attribute allocator) > This is a little different to skb field reservation. LSM is a general kernel framework which allows different security models to be implemented via a hook-based API. It is up to specific implementations to implement a policy (if any) for the skb security pointer. The LSM API provides a mechanism for this via hooks which are called at important points in the lifecycle of an skb, such as clone and copy as you mention. The hook declarations and documentation may be viewed at: http://sejanus.wirex.com:5555/anno/include/linux/security.hat_private?nav=index.html|src/.|src/include|src/include/linux > > > > This would be used by LSM modules for maintaining security attributes > > between layers. Note that this may also be useful for Freeswan, as it > > should be possible now to implement ipsec as an LSM module. > > Could you give a more detailed scenario what it would be needed for? > One scenario would be the use of packet labeling to implement mandatory access controls for IP networking. Labeling and access decisions may need to be made based on security conditions at various layers of the stack at specific points in time. For example, an outgoing packet might be labeled with the security attributes of the sending process and/or the object being transmitted. These attributes would need to be propagated between layers, and maintained throughout the life of the packet within the system. The latter is particularly critical in supporting security policy change, which may involve re/invalidating security attributes associated with packets. This scenario might also be extended to security processing performed in hardware, so there is a possibility of interelated labeling and access control decisions at every layer. (I'd prefer to show you some code, but I'm not aware of any projects of this nature which are ready for public consumption yet). Note that if someone was to come up with an acceptable skb field reservation scheme, then LSM would probably be able to make use of it. - James -- James Morris <jmorrisat_private> _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Oct 29 2001 - 04:19:52 PST