Thx Stephen! Now what I did is adding new patch in my source tree of 2.6.4. clone_tcp_sk is added into tcp_create_openreq_child function. Maybe it is not a good way . But it's working now :) Could you tell me the address of bk tree of 2.6.4 ? Why does mainline kernel not accept the network part of lsm in 2.6 ? For efficiency or else ? > 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 <sdsat_private> > National Security Agency > >
This archive was generated by hypermail 2b30 : Tue May 18 2004 - 19:26:32 PDT