On Aug 28, 2008, at 8:13 AM, Stephen Smalley wrote:
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).
Ah, OK. That is what I was looking for. Thanks, Casey and Stephen.
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.
Policy and we would need to consider the issues that Paul brought
up. Maybe the state of the socket would be helpful... I'll take a
look.
However it sounded like you could just use setsockcreatecon(3) to
achieve your goal, which would be cleaner than relabeling an existing
socket.
Yes, that works for what we are doing now. I'd be curious if someone
has a need beyond setting a label on creation.
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
Regards,
Trent.
----------------------------------------------
Trent Jaeger, Associate Professor
Pennsylvania State University, CSE Dept
346A IST Bldg, University Park, PA 16802
Email: tjaeger@xxxxxxxxxxx
Ph: (814) 865-1042, Fax: (814) 865-3176
--
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.
