On Wed, 2008-08-27 at 15:53 -0700, Casey Schaufler wrote: > Trent Jaeger wrote: > > > > On Aug 27, 2008, at 4:06 PM, Casey Schaufler wrote: > > > >> Stephen Smalley wrote: > >>> ... > >>> > >>> You may be right about setxattr not being viable due to it being an > >>> inode op. setsockopt may be the right approach there if we need to > >>> support relabeling of sockets at all. > >>> > >>> > >> > >> Hum. fsetxattr() works for Smack. The only thing that I can't do > >> is switch from labeled domains to unlabeled ones. So long as I'm > >> living "within CIPSO" it works great. Paul did a very good job on > >> that. If the intent is to change the MLS value, which is very useful > >> for label-aware service providers like CMW style X11 server or a > >> mail server, there oughtn't be a problem. > >> > >> Yes, it would be weird to change the label on a TCP connection > >> midstream, but not unheard of. If you need an example think of > >> what you might want to do with a diskless boot, or some of the > >> less sophisticated clustering schemes. For UDP examples should > >> be obvious to the casual observer, and a couple are cited above. > >> > >> Or am I missing something (again)? > > > > It sets the socket's inode's security context, but not the sock's context. > > Would I be going too far out on a limb to suggest you change the code > so that it changes both? I know that SELinux would require work > to figure out what context to put on the sock based on the context > of the task, socket inode, sock, port and address family, still > that shouldn't be an insurmountable obstacle. Especially if you > limit changes to the MLS portion of the label. Ok, Trent - have a look at smack_inode_setsecurity() for an example. There Casey specifically tests for a socket (via inode->i_sb->s_magic) and if it is a socket, he extracts the struct socket via SOCKET_I(inode), using the magic of containerof (i.e. embedded data structure). We could do likewise to support updating the secid in both the inode and the sock simultaneously upon fsetxattr of security.selinux. This would still be subject to policy, of course. However it sounded like you could just use setsockcreatecon(3) to achieve your goal, which would be cleaner than relabeling an existing socket. > Paul points out some edge case conditions for TCP that might make > really supporting that protocol iffy. True enough. I wouldn't see > changing labels on a TCP connection showing up in any but very low > level system sort of uses where you need to be extraordinarily > careful in any case. I don't see those dangers as a real stopper. -- Stephen Smalley National Security Agency -- 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.
