On Wednesday 01 July 2009 11:42:19 am Stephen Smalley wrote: > On Wed, 2009-07-01 at 11:19 -0400, Paul Moore wrote: > > On Wednesday 01 July 2009 11:06:51 am Stephen Smalley wrote: > > > On Wed, 2009-07-01 at 11:01 -0400, Eric Paris wrote: > > > > On Wed, Jul 1, 2009 at 9:44 AM, Stephen Smalley<sds@xxxxxxxxxxxxx> wrote: > > > > > On Tue, 2009-06-30 at 17:34 -0400, Paul Moore wrote: > > > > > > > > > > Wouldn't it be a bug if they didn't match? So I'd add the > > > > > sk_alloc() hook, set the label/SID for the sock there, and remove > > > > > the setting of the sock label/SID from post_create. And then just > > > > > add a BUG_ON to post_create to assert that the inode SID should be > > > > > the same as the sock SID and if they don't match something has gone > > > > > wrong. > > > > > > > > I've got a system all set up to test anything you want/have/need.... > > > > Maybe this afternoon I'll even give this suggestion a try just to see > > > > what happens, the networking hooks are ummmm, special? > > > > > > Wait - we already have a sk_alloc_security hook. > > > > Yep, this is where we would set the sock's label/SID. > > > > > And IIRC, we don't set the SID/label there because that can happen when > > > a new connection sock is created, and thus outside of process context. > > > > This gets back to my original comments about "ugliness". New incoming > > connection sockets should get labeled correctly before use through the > > inet_conn_request() and inet_csk_clone() hooks. While admittedly, there > > is the potential for the sock to be labeled incorrectly immediately after > > allocation, but this is not very different from what we have today (sock > > is initially labeled with unlabeled_t). > > unlabeled_t is easily noticeable in denials (as in this case) and > correctly reflects the state of the socket - it isn't yet labeled. > Setting the sid from the task sid of some random task that happens to be > referenced by current when the new connection is initiated seems a > little more prone to danger if it happens to not get set by the other > hooks later. Well, if we can't do it in sk_alloc() then I think we are stuck with a new hook; which just seems wrong. -- paul moore linux @ hp -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
