Re: Socket and inode label consistency

[Casey Schaufler <casey@schaufler-ca.com>]

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.

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.

> The former is used to authorize access to the socket api.  The latter 
> is what is used to authorize packet access (e.g., labeled ipsec and 
> seclabel).  So, you end up with the two being different which is a 
> potential problem.
>
> Regards,
> Trent.
> ----------------------------------------------
> Trent Jaeger, Associate Professor
> Pennsylvania State University, CSE Dept
> 346A IST Bldg, University Park, PA 16802
> Email: tjaeger@cse.psu.edu
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.