Re: Seriously, again, about inode_post_removexattr

2007-04-11 Thread Tetsuo Handa
Hello. Stephen Smalley wrote: > You need to do it in another hook, like sock_rcv_skb or > inet_conn_request, and drop the connection before it is established. Is it OK to filter before connection is established? How do you handle the following situation? /bin/daytime runs in the daytime_t domai

Re: Seriously, again, about inode_post_removexattr

2007-04-10 Thread Stephen Smalley
On Tue, 2007-04-10 at 09:11 -0400, Stephen Smalley wrote: > On Tue, 2007-04-10 at 21:35 +0900, Tetsuo Handa wrote: > > Hello. > > > > Stephen Smalley wrote: > > > It doesn't do any good to return an error _after_ the new connection has > > > been set up or the data transfer has already happened.

Re: Seriously, again, about inode_post_removexattr

2007-04-10 Thread Stephen Smalley
On Tue, 2007-04-10 at 21:35 +0900, Tetsuo Handa wrote: > Hello. > > Stephen Smalley wrote: > > It doesn't do any good to return an error _after_ the new connection has > > been set up or the data transfer has already happened. Userspace > > already has what it needs and another thread can already

Re: Seriously, again, about inode_post_removexattr

2007-04-10 Thread Tetsuo Handa
Hello. Stephen Smalley wrote: > It doesn't do any good to return an error _after_ the new connection has > been set up or the data transfer has already happened. Userspace > already has what it needs and another thread can already begin using it > _before_ you take any action in those post hooks.

Re: Seriously, again, about inode_post_removexattr

2007-04-09 Thread Kazuki Omo(Company)
Hi, Hao, > Thank you for your information! The mappings are very useful! > I'm sure that your mapping sheets are very good reference materials > for people who are doing linux kernel security enhancements, thanks again! > I'm very glad if those materials are useful for people's work :-) > How di

Re: Seriously, again, about inode_post_removexattr

2007-04-09 Thread Stephen Smalley
On Sun, 2007-04-08 at 13:08 +0800, Hao Xu wrote: > Hi! > > If the purpose of the LSM framework is not just satisfying selinux, then > the reason for adding this hook is obvious: we NEED a way to update the > incore inode security data after successful removexattr operations, it's > undoubtedly nec

Re: Seriously, again, about inode_post_removexattr

2007-04-09 Thread Stephen Smalley
On Sun, 2007-04-08 at 19:45 +0900, Tetsuo Handa wrote: > Hello. > > Hao Xu wrote: > > If the purpose of the LSM framework is not just satisfying selinux, then > I also want LSM framework add some hooks. > > The problems are at accept() and recvmsg() operation. > I want to return error on security

Re: Seriously, again, about inode_post_removexattr

2007-04-09 Thread Paul Moore
On Sunday, April 8 2007 6:45:54 am Tetsuo Handa wrote: > I want to return error on security_socket_post_accept(). The problem is that there is no way to un-accept a connection, once you have accepted it. This was discussed in several threads on the SELinux and netdev mailing lists last year as

Re: Seriously, again, about inode_post_removexattr

2007-04-08 Thread Hao Xu
Tetsuo Handa 写道: I also want LSM framework add some hooks. The problems are at accept() and recvmsg() operation. I want to return error on security_socket_post_accept(). I want a new hook security_socket_post_recvmsg() that are called AFTER sock_recvmsg() is called. Yes, for some LSM hooks,

Re: Seriously, again, about inode_post_removexattr

2007-04-08 Thread Hao Xu
Kazuki Omo(Company) 写道: > I'm not sure this information is useful or not, but I just made > Sysmtecalls <-> security functions/capabilities mapping > sheets for understanding LSM's framework(and enhancement LIDS:-) ). > > You can download some Excel sheets from; > http://www.selinux.gr.jp/LIDS-JP/s

Re: Seriously, again, about inode_post_removexattr

2007-04-08 Thread Tetsuo Handa
Hello. Hao Xu wrote: > If the purpose of the LSM framework is not just satisfying selinux, then I also want LSM framework add some hooks. The problems are at accept() and recvmsg() operation. I want to return error on security_socket_post_accept(). I want a new hook security_socket_post_recvmsg()

Re: Seriously, again, about inode_post_removexattr

2007-04-08 Thread Kazuki Omo(Company)
Hi, I'm not sure this information is useful or not, but I just made Sysmtecalls <-> security functions/capabilities mapping sheets for understanding LSM's framework(and enhancement LIDS:-) ). You can download some Excel sheets from; http://www.selinux.gr.jp/LIDS-JP/systemcalls.html (These Excel s

Seriously, again, about inode_post_removexattr

2007-04-07 Thread Hao Xu
Hi! If the purpose of the LSM framework is not just satisfying selinux, then the reason for adding this hook is obvious: we NEED a way to update the incore inode security data after successful removexattr operations, it's undoubtedly necessary for a xattr based security module. I don't consider th