On Tue, 2004-05-18 at 02:11, Yuan Chunyang wrote: > Some questions about LSM hooks "sk_alloc_security" in 2.6 are > puzzling me. > > Attaching a security structer to sk->security field of sock is > hook function: > In 2.6 is : > int (*sk_alloc_security) (struct sock *sk, int family, int priority); > In 2.5.72 is : > int (*socket_sock_alloc_security) (struct sock * sk, int gfp_mask); > > I developed something in 2.5.72 using hook of " > socket_sock_alloc_security " to attach a security structer to > sk->security field . It's OK! But when I port it to 2.6.4, I find that > only PF_UNIX sock can be attached security structer in > sk_alloc_security function. And the PF_INET sock can not be attached > to security structer, i.e. I can not start winX in 2.6.4 . But the > locations of two hook functions are the same. > > Can someone tell me the reason? > How about attaching a security structer to sk->security field for PF_INET sock or else type sock? The LSM networking security fields and hooks were not accepted into the mainline Linux kernel during the 2.5 development series, and are thus not present in the Linux 2.6 stable series. The SELinux module was reworked to provide as much network access control functionality as possible using only the fields and hooks that were accepted into mainline plus the use of NetFilter. To support getpeercon functionality (the ability to get the security context of the peer of a connected Unix domain socket), we were able to get sk_alloc_security and sk_free_security hooks into the mainline kernel for Unix domain sockets. In the case of INET sockets, using the security field safely requires at least the clone_tcp_sk change to avoid clobbering the security field of newly created server sockets and double-freeing the security structure copied from the listening socket. That change is _not_ in mainline Linux 2.6, although I think it is still present in the LSM BitKeeper tree. So I am not sure why you are having a problem with using it if you are working off of the lsm-2.6 tree, but it definitely won't work with a mainline kernel. In general, working off the lsm-2.6 BitKeeper tree and patch is likely not a good idea if you want your security module to work with a mainline kernel, as it still includes a number of hooks and security fields that were never accepted into mainline. Also, it looks like the lsm-2.6 BitKeeper tree is a bit out of date; last re-based to 2.6.4 (vs. the current 2.6.6 mainline kernel). I think that all active development is being done directly against the mainline kernel at this point. > *** Another question *** : > Why take the tcp hooks out of LSM in 2.6 , such as tcp_create_openreq_child ? As mentioned above, the networking hooks and security fields were not accepted into Linux 2.5, and are thus not in Linus 2.6. See the SELinux module in the mainline kernel for an example of what you can still do using just the socket layer hooks and NetFilter. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2b30 : Tue May 18 2004 - 05:08:51 PDT