On Fri, 20 Jul 2001, Chris Vance wrote: > This patch makes no attempts to secure skbuffs or network devices. We are > still working towards an implementation that is most likely to be accepted > by the kernel folks. To that end, we are going to see what we can do with > the netfilter code rather than directly modifying the ip input/ouput > routines or modifying the sk_buff structure (which apparently would be > difficult to gain approval for). If anyone has any relevant insight, I > would welcome it. Implementing LSM hooks via Netfilter would provide a simple way to make access decsisions and possibly modify packets (e.g. encryption) at useful points within the network layer (namely: prerouting, forwarding, postrouting, local in and local out), but it may not help if there is a need to propagate security context to the transport layer. For example, you may want to make an access decision for incoming packets based on the user who is about to receive them. This is not known at the network layer, and the decsision can only be made further up in the stack, after the network layer header has been pulled from the skb. Also, there is the issue of packet labeling, which is often performed at the network layer (e.g. via IP options) which may need to be propagated to the transport layer for each datagram and sub-stream segment. There may even be a need to label packets differently depending on whether they were processed with a specific type of network device (keeping in mind the trend towards more complex network processing being done in hardware). As far as I can tell, the best way to acheive this for the general case is to attach an opaque blob to the skb. It's very difficult to guess how the network maintainers would react to this. From my reading of comments previously made on similar issues, it seems that objections may include: - lack of generality - poor design (e.g. protocol layering violation) - performance reduction caused by bloating network structures and the finely tuned network fast path (good people have sweated blood on this :-) Addressing the first two issues, I would suggest that LSM is a potentially fundamental aspect of the kernel and is thus is part of a general mechanism, and that security context needs to be propogated between network layers for MAC security models (at least). For performance, it is very difficult to know unless there is at least some code to look at. It is possible that the LSM hooks may need to be implemented as macros in the networking code. Those who wish to run things like Mindcraft tests would simply then be advised to disable high assurance security features. Anyway, I will have a look at this over the weekend, and see if I can come up with something which might be useful as a discussion point. - 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 : Fri Jul 20 2001 - 19:33:32 PDT