I find it hard to believe that there have been no additional comments on this patch. Should I assume that everything is fine and that it will be commited shortly or should I assume that everyone has been too busy thinking about file descriptors to take a look at it? Off-list I have received only a couple comments. One asked if it would be useful to have a post_accept hook. I originally had hooks for post_accept and post_connect, but removed them due to a lack of usefulness. In the case of connect, too much processing has occurred by the time a post hook can be placed in net/socket.c - the same is likely true for accept as well. It seems inappropriate to have the ability to make an access-control based decision after the fact -- added to which is the issue of unrolling any performed operations. This moved me to make the two post hooks return void and simply be used to update state information. I believe all state information can be maintained by the normal hook (in both cases, the new socket is available). I'm also a bit unclear on the implications of race conditions/timing with regards to the connection being established and then later shut down. Can another application thread gain access to the resource following establishment but before a post function can deny and shut down the socket? Again this leans towards post functions that return void - and hence have reduced utility. For these reasons, I decided NOT to include post_accept or post_connect hooks. If someone else can determine a way to safely include them, or suggest alternate locations (netfilter?) I would welcome the help. Off-list, Steve Smalley also added: "the original SELinux prototype inserted code directly at the TCP layer to control connection establishment during the three-way handshake. However, LSM currently doesn't have any hooks in the TCP/IP implementation, and we are trying to investigate the extent to which we can implement the SELinux controls via a combination of hooks in the socket layer and hooks in the netfilter code. We ultimately may need to insert hooks directly into the TCP implementation as well, but we're trying to minimize such changes in order to ease acceptance by the kernel developers." As he explained (better than I could have), this is what we are currently exploring. However, it should not affect the acceptance of this patch. These issues will be presented to the list in a future patch, independent from this one. Just to to be perfectly clear, this patch is separate from the ongoing netfilter/skb/netdevice work and does not include post_accept or post_connect hooks. chris. On Mon, 23 Jul 2001, Chris Vance wrote: > > Attached is a patch that is identical to the first, with the exception > that the extra user-space parameters have been removed from the accept and > setsockopt hooks. This new patch should replace the previously posted > one. > > chris. > > On Fri, 20 Jul 2001, Greg KH wrote: > > > On Fri, Jul 20, 2001 at 04:09:31PM -0400, Chris Vance wrote: > > > > > > Something escaped my first pass. Note that two of these hooks have > > > parameters that are user-space variables - accept and setsockopt. In the > > > first case, accept, they should be removed. In the second case, > > > setsockopt, it's not clear whether an LSM module would care precisely what > > > value is being set. It would need to be copied into kernel memory and the > > > possibly of a race condition exists. > > > > > > Perhaps removing these paramters would be the safest thing to do. > > > > I agree. Keeping lsm modules from having to handle userspace variables > > is a good thing. Where ever possible I think we should try to avoid it. > > > > Other than that, the patch looks nice. However I don't profess to know > > anything about the network stack code :) > > > > Anyone else want to comment if these hooks will work out for their > > projects? > > > > thanks, > > > > greg k-h > > > _______________________________________________ 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 : Wed Jul 25 2001 - 07:37:48 PDT