Socket and inode label consistency

Socket and inode label consistency

[Trent Jaeger]

Hi,

I see on the Kernel Development To Do list at http:// 
selinuxproject.org/page/Kernel_Development that the following task is  
identified:

"Full APIs for getting and setting security contexts of sockets and  
IPC objects. Ensure that socket context is kept consistent on socket  
inode and sock structures when changed."

We are being bitten by this now, so I am wondering if anyone is  
working on it or wishes to discuss how to proceed.  We would be  
interested in addressing this issue.

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.

Re: Socket and inode label consistency

[Stephen Smalley]

On Tue, 2008-08-26 at 20:50 -0400, Trent Jaeger wrote:
> Hi,
> 
> I see on the Kernel Development To Do list at http:// 
> selinuxproject.org/page/Kernel_Development that the following task is  
> identified:
> 
> "Full APIs for getting and setting security contexts of sockets and  
> IPC objects. Ensure that socket context is kept consistent on socket  
> inode and sock structures when changed."
> 
> We are being bitten by this now, so I am wondering if anyone is  
> working on it or wishes to discuss how to proceed.  We would be  
> interested in addressing this issue.

I don't know of anyone working on it, but we are interested in it.
As I recall, you can get and set the socket inode label via fgetxattr
and fsetxattr but the struct sock label isn't accessible from userspace
(except via getpeercon, and then only for the peer).  I think you'd need
to add a .setxattr method to the socket_file_ops and have them call into
the LSM interface to update the sock information (as well as continuing
to update the socket inode info).

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Socket and inode label consistency

[Paul Moore]

On Wednesday 27 August 2008 7:57:34 am Stephen Smalley wrote:
> On Tue, 2008-08-26 at 20:50 -0400, Trent Jaeger wrote:
> > Hi,
> >
> > I see on the Kernel Development To Do list at http://
> > selinuxproject.org/page/Kernel_Development that the following task
> > is identified:
> >
> > "Full APIs for getting and setting security contexts of sockets and
> > IPC objects. Ensure that socket context is kept consistent on
> > socket inode and sock structures when changed."
> >
> > We are being bitten by this now, so I am wondering if anyone is
> > working on it or wishes to discuss how to proceed.  We would be
> > interested in addressing this issue.
>
> I don't know of anyone working on it, but we are interested in it.

It is something that has been on my todo list for some time but it is 
stuck with such a low priority that I haven't been able to make any 
progress on it.  If you've got time to work on it, I would be very 
happy :)

> As I recall, you can get and set the socket inode label via fgetxattr
> and fsetxattr but the struct sock label isn't accessible from
> userspace (except via getpeercon, and then only for the peer).  I
> think you'd need to add a .setxattr method to the socket_file_ops and
> have them call into the LSM interface to update the sock information
> (as well as continuing to update the socket inode info).

There would also need to be some work done to ensure that all the 
outbound labeled networking stuff is updated when the socket's label is 
changed via the xattr operations.  Right now there is no way (at least 
not that I know of) to change the label of an existing socket so we 
don't have to worry about that problem.

I also wonder about changing the label of a socket while it is 
connected, probably not a big issue for dgram sockets but I think it 
could get pretty strange for stream sockets.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Socket and inode label consistency

[Eric Paris]

On Wed, 2008-08-27 at 14:08 -0400, Trent Jaeger wrote:
> 
> On Aug 27, 2008, at 11:49 AM, Paul Moore wrote:
> > On Wednesday 27 August 2008 7:57:34 am Stephen Smalley wrote:
> > > On Tue, 2008-08-26 at 20:50 -0400, Trent Jaeger wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > I see on the Kernel Development To Do list at http://
> > > > selinuxproject.org/page/Kernel_Development that the following
> > > > task
> > > > is identified:
> > > > 
> > > > 
> > > > "Full APIs for getting and setting security contexts of sockets
> > > > and
> > > > IPC objects. Ensure that socket context is kept consistent on
> > > > socket inode and sock structures when changed."
> > > > 
> > > > 
> > > > We are being bitten by this now, so I am wondering if anyone is
> > > > working on it or wishes to discuss how to proceed.  We would be
> > > > interested in addressing this issue.
> > > 
> > > 
> > > I don't know of anyone working on it, but we are interested in it.
> > 
> > 
> > It is something that has been on my todo list for some time but it
> > is 
> > stuck with such a low priority that I haven't been able to make any 
> > progress on it.  If you've got time to work on it, I would be very 
> > happy :)
> > 
> > 
> > > As I recall, you can get and set the socket inode label via
> > > fgetxattr
> > > and fsetxattr but the struct sock label isn't accessible from
> > > userspace (except via getpeercon, and then only for the peer).  I
> > > think you'd need to add a .setxattr method to the socket_file_ops
> > > and
> > > have them call into the LSM interface to update the sock
> > > information
> > > (as well as continuing to update the socket inode info).
> > 
> > 
> > There would also need to be some work done to ensure that all the 
> > outbound labeled networking stuff is updated when the socket's label
> > is 
> > changed via the xattr operations.  Right now there is no way (at
> > least 
> > not that I know of) to change the label of an existing socket so we 
> > don't have to worry about that problem.
> > 
> > 
> > I also wonder about changing the label of a socket while it is 
> > connected, probably not a big issue for dgram sockets but I think
> > it 
> > could get pretty strange for stream sockets.
> 
> 
> Hi,
> 
> 
> What we want is to create a socket within the context of a multilevel
> secure process.  For example, if the process has an MLS range of
> s0-s1, we may want an s0 or s1 socket.  
> 
> 
> Thus, in theory, we should be able to avoid dealing with context
> changes on connected sockets and such.  Once the socket goes into any
> use, it cannot be relabeled.
> 
> 
> I am not sure that setxattr will work as this is an inode operation,
> and I do not see a reference from an inode to an associated socket.  
> 
> 
> Originally, I was thinking of setsockopt, but I agree that it would be
> nice to deal with it via the file interface, like fsetfilecon.

/proc/self/attr/sockcreate and I know I wrote some libselinux stuff
around it too....

-Eric



--
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.

Re: Socket and inode label consistency

[Trent Jaeger]

[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]


On Aug 27, 2008, at 11:49 AM, Paul Moore wrote:

> On Wednesday 27 August 2008 7:57:34 am Stephen Smalley wrote:
>> On Tue, 2008-08-26 at 20:50 -0400, Trent Jaeger wrote:
>>> Hi,
>>>
>>> I see on the Kernel Development To Do list at http://
>>> selinuxproject.org/page/Kernel_Development that the following task
>>> is identified:
>>>
>>> "Full APIs for getting and setting security contexts of sockets and
>>> IPC objects. Ensure that socket context is kept consistent on
>>> socket inode and sock structures when changed."
>>>
>>> We are being bitten by this now, so I am wondering if anyone is
>>> working on it or wishes to discuss how to proceed.  We would be
>>> interested in addressing this issue.
>>
>> I don't know of anyone working on it, but we are interested in it.
>
> It is something that has been on my todo list for some time but it is
> stuck with such a low priority that I haven't been able to make any
> progress on it.  If you've got time to work on it, I would be very
> happy :)
>
>> As I recall, you can get and set the socket inode label via fgetxattr
>> and fsetxattr but the struct sock label isn't accessible from
>> userspace (except via getpeercon, and then only for the peer).  I
>> think you'd need to add a .setxattr method to the socket_file_ops and
>> have them call into the LSM interface to update the sock information
>> (as well as continuing to update the socket inode info).
>
> There would also need to be some work done to ensure that all the
> outbound labeled networking stuff is updated when the socket's  
> label is
> changed via the xattr operations.  Right now there is no way (at least
> not that I know of) to change the label of an existing socket so we
> don't have to worry about that problem.
>
> I also wonder about changing the label of a socket while it is
> connected, probably not a big issue for dgram sockets but I think it
> could get pretty strange for stream sockets.

Hi,

What we want is to create a socket within the context of a multilevel  
secure process.  For example, if the process has an MLS range of s0- 
s1, we may want an s0 or s1 socket.

Thus, in theory, we should be able to avoid dealing with context  
changes on connected sockets and such.  Once the socket goes into any  
use, it cannot be relabeled.

I am not sure that setxattr will work as this is an inode operation,  
and I do not see a reference from an inode to an associated socket.

Originally, I was thinking of setsockopt, but I agree that it would  
be nice to deal with it via the file interface, like fsetfilecon.

Thoughts?

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




[-- Attachment #2: Type: text/html, Size: 8915 bytes --]

Re: Socket and inode label consistency

[Stephen Smalley]

On Wed, 2008-08-27 at 14:08 -0400, Trent Jaeger wrote:
> 
> On Aug 27, 2008, at 11:49 AM, Paul Moore wrote:
> > On Wednesday 27 August 2008 7:57:34 am Stephen Smalley wrote:
> > > On Tue, 2008-08-26 at 20:50 -0400, Trent Jaeger wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > I see on the Kernel Development To Do list at http://
> > > > selinuxproject.org/page/Kernel_Development that the following
> > > > task
> > > > is identified:
> > > > 
> > > > 
> > > > "Full APIs for getting and setting security contexts of sockets
> > > > and
> > > > IPC objects. Ensure that socket context is kept consistent on
> > > > socket inode and sock structures when changed."
> > > > 
> > > > 
> > > > We are being bitten by this now, so I am wondering if anyone is
> > > > working on it or wishes to discuss how to proceed.  We would be
> > > > interested in addressing this issue.
> > > 
> > > 
> > > I don't know of anyone working on it, but we are interested in it.
> > 
> > 
> > It is something that has been on my todo list for some time but it
> > is 
> > stuck with such a low priority that I haven't been able to make any 
> > progress on it.  If you've got time to work on it, I would be very 
> > happy :)
> > 
> > 
> > > As I recall, you can get and set the socket inode label via
> > > fgetxattr
> > > and fsetxattr but the struct sock label isn't accessible from
> > > userspace (except via getpeercon, and then only for the peer).  I
> > > think you'd need to add a .setxattr method to the socket_file_ops
> > > and
> > > have them call into the LSM interface to update the sock
> > > information
> > > (as well as continuing to update the socket inode info).
> > 
> > 
> > There would also need to be some work done to ensure that all the 
> > outbound labeled networking stuff is updated when the socket's label
> > is 
> > changed via the xattr operations.  Right now there is no way (at
> > least 
> > not that I know of) to change the label of an existing socket so we 
> > don't have to worry about that problem.
> > 
> > 
> > I also wonder about changing the label of a socket while it is 
> > connected, probably not a big issue for dgram sockets but I think
> > it 
> > could get pretty strange for stream sockets.
> 
> 
> Hi,
> 
> 
> What we want is to create a socket within the context of a multilevel
> secure process.  For example, if the process has an MLS range of
> s0-s1, we may want an s0 or s1 socket.  
> 
> 
> Thus, in theory, we should be able to avoid dealing with context
> changes on connected sockets and such.  Once the socket goes into any
> use, it cannot be relabeled.
> 
> 
> I am not sure that setxattr will work as this is an inode operation,
> and I do not see a reference from an inode to an associated socket.  
> 
> 
> Originally, I was thinking of setsockopt, but I agree that it would be
> nice to deal with it via the file interface, like fsetfilecon.

If you know the label you want to use for the socket _before_ you create
it, you can just use setsockcreatecon() prior to calling socket().

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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Socket and inode label consistency

[Trent Jaeger]

[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]


On Aug 27, 2008, at 2:05 PM, Eric Paris wrote:

> On Wed, 2008-08-27 at 14:08 -0400, Trent Jaeger wrote:
>>
>> On Aug 27, 2008, at 11:49 AM, Paul Moore wrote:
>>> On Wednesday 27 August 2008 7:57:34 am Stephen Smalley wrote:
>>>> On Tue, 2008-08-26 at 20:50 -0400, Trent Jaeger wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> I see on the Kernel Development To Do list at http://
>>>>> selinuxproject.org/page/Kernel_Development that the following
>>>>> task
>>>>> is identified:
>>>>>
>>>>>
>>>>> "Full APIs for getting and setting security contexts of sockets
>>>>> and
>>>>> IPC objects. Ensure that socket context is kept consistent on
>>>>> socket inode and sock structures when changed."
>>>>>
>>>>>
>>>>> We are being bitten by this now, so I am wondering if anyone is
>>>>> working on it or wishes to discuss how to proceed.  We would be
>>>>> interested in addressing this issue.
>>>>
>>>>
>>>> I don't know of anyone working on it, but we are interested in it.
>>>
>>>
>>> It is something that has been on my todo list for some time but it
>>> is
>>> stuck with such a low priority that I haven't been able to make any
>>> progress on it.  If you've got time to work on it, I would be very
>>> happy :)
>>>
>>>
>>>> As I recall, you can get and set the socket inode label via
>>>> fgetxattr
>>>> and fsetxattr but the struct sock label isn't accessible from
>>>> userspace (except via getpeercon, and then only for the peer).  I
>>>> think you'd need to add a .setxattr method to the socket_file_ops
>>>> and
>>>> have them call into the LSM interface to update the sock
>>>> information
>>>> (as well as continuing to update the socket inode info).
>>>
>>>
>>> There would also need to be some work done to ensure that all the
>>> outbound labeled networking stuff is updated when the socket's label
>>> is
>>> changed via the xattr operations.  Right now there is no way (at
>>> least
>>> not that I know of) to change the label of an existing socket so we
>>> don't have to worry about that problem.
>>>
>>>
>>> I also wonder about changing the label of a socket while it is
>>> connected, probably not a big issue for dgram sockets but I think
>>> it
>>> could get pretty strange for stream sockets.
>>
>>
>> Hi,
>>
>>
>> What we want is to create a socket within the context of a multilevel
>> secure process.  For example, if the process has an MLS range of
>> s0-s1, we may want an s0 or s1 socket.
>>
>>
>> Thus, in theory, we should be able to avoid dealing with context
>> changes on connected sockets and such.  Once the socket goes into any
>> use, it cannot be relabeled.
>>
>>
>> I am not sure that setxattr will work as this is an inode operation,
>> and I do not see a reference from an inode to an associated socket.
>>
>>
>> Originally, I was thinking of setsockopt, but I agree that it  
>> would be
>> nice to deal with it via the file interface, like fsetfilecon.
>
> /proc/self/attr/sockcreate and I know I wrote some libselinux stuff
> around it too....

OK.  We'll take a look.

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




[-- Attachment #2: Type: text/html, Size: 13794 bytes --]

Re: Socket and inode label consistency

[Trent Jaeger]

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]


On Aug 27, 2008, at 2:16 PM, Stephen Smalley wrote:

>
> On Wed, 2008-08-27 at 14:08 -0400, Trent Jaeger wrote:
>>
>> On Aug 27, 2008, at 11:49 AM, Paul Moore wrote:
>>> On Wednesday 27 August 2008 7:57:34 am Stephen Smalley wrote:
>>>> On Tue, 2008-08-26 at 20:50 -0400, Trent Jaeger wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> I see on the Kernel Development To Do list at http://
>>>>> selinuxproject.org/page/Kernel_Development that the following
>>>>> task
>>>>> is identified:
>>>>>
>>>>>
>>>>> "Full APIs for getting and setting security contexts of sockets
>>>>> and
>>>>> IPC objects. Ensure that socket context is kept consistent on
>>>>> socket inode and sock structures when changed."
>>>>>
>>>>>
>>>>> We are being bitten by this now, so I am wondering if anyone is
>>>>> working on it or wishes to discuss how to proceed.  We would be
>>>>> interested in addressing this issue.
>>>>
>>>>
>>>> I don't know of anyone working on it, but we are interested in it.
>>>
>>>
>>> It is something that has been on my todo list for some time but it
>>> is
>>> stuck with such a low priority that I haven't been able to make any
>>> progress on it.  If you've got time to work on it, I would be very
>>> happy :)
>>>
>>>
>>>> As I recall, you can get and set the socket inode label via
>>>> fgetxattr
>>>> and fsetxattr but the struct sock label isn't accessible from
>>>> userspace (except via getpeercon, and then only for the peer).  I
>>>> think you'd need to add a .setxattr method to the socket_file_ops
>>>> and
>>>> have them call into the LSM interface to update the sock
>>>> information
>>>> (as well as continuing to update the socket inode info).
>>>
>>>
>>> There would also need to be some work done to ensure that all the
>>> outbound labeled networking stuff is updated when the socket's label
>>> is
>>> changed via the xattr operations.  Right now there is no way (at
>>> least
>>> not that I know of) to change the label of an existing socket so we
>>> don't have to worry about that problem.
>>>
>>>
>>> I also wonder about changing the label of a socket while it is
>>> connected, probably not a big issue for dgram sockets but I think
>>> it
>>> could get pretty strange for stream sockets.
>>
>>
>> Hi,
>>
>>
>> What we want is to create a socket within the context of a multilevel
>> secure process.  For example, if the process has an MLS range of
>> s0-s1, we may want an s0 or s1 socket.
>>
>>
>> Thus, in theory, we should be able to avoid dealing with context
>> changes on connected sockets and such.  Once the socket goes into any
>> use, it cannot be relabeled.
>>
>>
>> I am not sure that setxattr will work as this is an inode operation,
>> and I do not see a reference from an inode to an associated socket.
>>
>>
>> Originally, I was thinking of setsockopt, but I agree that it  
>> would be
>> nice to deal with it via the file interface, like fsetfilecon.
>
> If you know the label you want to use for the socket _before_ you  
> create
> it, you can just use setsockcreatecon() prior to calling socket().
>
> 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.

OK.  That sounds like that will suffice as well.  Thanks, everyone.

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




[-- Attachment #2: Type: text/html, Size: 14625 bytes --]

Re: Socket and inode label consistency

[Paul Moore]

On Wednesday 27 August 2008 2:20:48 pm Trent Jaeger wrote:
> On Aug 27, 2008, at 2:05 PM, Eric Paris wrote:
> >> Hi,
> >>
> >>
> >> What we want is to create a socket within the context of a
> >> multilevel secure process.  For example, if the process has an MLS
> >> range of s0-s1, we may want an s0 or s1 socket.
> >>
> >>
> >> Thus, in theory, we should be able to avoid dealing with context
> >> changes on connected sockets and such.  Once the socket goes into
> >> any use, it cannot be relabeled.
> >>
> >>
> >> I am not sure that setxattr will work as this is an inode
> >> operation, and I do not see a reference from an inode to an
> >> associated socket.
> >>
> >>
> >> Originally, I was thinking of setsockopt, but I agree that it
> >> would be
> >> nice to deal with it via the file interface, like fsetfilecon.
> >
> > /proc/self/attr/sockcreate and I know I wrote some libselinux stuff
> > around it too....
>
> OK.  We'll take a look.

Yeah, as others have said setsockcreatecon() is your friend here.  If 
you need a working example there is a test utility included in the 
audit-test project on sourceforge[1] which uses setsockcreatecon() to 
create some strangely labeled sockets.  If you download the audit-test 
sources the tool can be found in utils/network-server; it isn't the 
prettiest piece of code but it works ;)

If you have any questions or problems don't hesitate to ask.

[1] http://sourceforge.net/projects/audit-test

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Socket and inode label consistency

[Casey Schaufler]

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)?


--
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.

Re: Socket and inode label consistency

[Trent Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]


On Aug 27, 2008, at 2:34 PM, Paul Moore wrote:

> On Wednesday 27 August 2008 2:20:48 pm Trent Jaeger wrote:
>> On Aug 27, 2008, at 2:05 PM, Eric Paris wrote:
>>>> Hi,
>>>>
>>>>
>>>> What we want is to create a socket within the context of a
>>>> multilevel secure process.  For example, if the process has an MLS
>>>> range of s0-s1, we may want an s0 or s1 socket.
>>>>
>>>>
>>>> Thus, in theory, we should be able to avoid dealing with context
>>>> changes on connected sockets and such.  Once the socket goes into
>>>> any use, it cannot be relabeled.
>>>>
>>>>
>>>> I am not sure that setxattr will work as this is an inode
>>>> operation, and I do not see a reference from an inode to an
>>>> associated socket.
>>>>
>>>>
>>>> Originally, I was thinking of setsockopt, but I agree that it
>>>> would be
>>>> nice to deal with it via the file interface, like fsetfilecon.
>>>
>>> /proc/self/attr/sockcreate and I know I wrote some libselinux stuff
>>> around it too....
>>
>> OK.  We'll take a look.
>
> Yeah, as others have said setsockcreatecon() is your friend here.  If
> you need a working example there is a test utility included in the
> audit-test project on sourceforge[1] which uses setsockcreatecon() to
> create some strangely labeled sockets.  If you download the audit-test
> sources the tool can be found in utils/network-server; it isn't the
> prettiest piece of code but it works ;)
>
> If you have any questions or problems don't hesitate to ask.
>
> [1] http://sourceforge.net/projects/audit-test
>

That is great.  Thanks.

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




[-- Attachment #2: Type: text/html, Size: 7894 bytes --]

Re: Socket and inode label consistency

[Paul Moore]

On Wednesday 27 August 2008 4:06:55 pm Casey Schaufler wrote:
> 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.

Speaking purely in regards to the current Linux implementation, the 
thing that concerns me about stream sockets is that it is difficult, if 
not impossible, to ensure that the relabel happens at a specific data 
boundary in the stream.  Retransmission is another issue but might work 
okay depending where in the kernel the queue/retransmission takes 
place, I would need to check that.  I suppose all of these things can 
be addressed but it would be take a little bit of work and until I see 
an application/user that needs this functionality I can't justify 
spending time on it (my todo list is already way too long).

If you look carefully at the new labeled networking bits for 2.6.28 you 
will see that while we add the ability to change labeling based on the 
destination address, we do not allow labeling to change on an existing 
connection (although you can disconnect and reconnect a socket to a 
different destination allowing you to change the network labeling).

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Socket and inode label consistency

[Trent Jaeger]

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.  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.

Re: Socket and inode label consistency

[Casey Schaufler]

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.

Re: Socket and inode label consistency

[Stephen Smalley]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Socket and inode label consistency

[Trent Jaeger]

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@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.

Re: Socket and inode label consistency

[Casey Schaufler]

Trent Jaeger wrote:
> ...
>>
>> 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.
>

Sure, any service that wants to serve clients with a variety of labels.
The X server is an obvious candidate. A multi-label message bus. Label
aware sendmail. xinetd. Name services (the YP/NIS of the day). Anywhere
you want the label of the response to depend on the label of the request.
Yes, we're talking about Trusted Applications here, and specially coded
ones at that. Sometimes that's the best way.



--
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.

Re: Socket and inode label consistency

[Stephen Smalley]

On Thu, 2008-08-28 at 21:22 -0700, Casey Schaufler wrote:
> Trent Jaeger wrote:
> > ...
> >>
> >> 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.
> >
> 
> Sure, any service that wants to serve clients with a variety of labels.
> The X server is an obvious candidate. A multi-label message bus. Label
> aware sendmail. xinetd. Name services (the YP/NIS of the day). Anywhere
> you want the label of the response to depend on the label of the request.
> Yes, we're talking about Trusted Applications here, and specially coded
> ones at that. Sometimes that's the best way.

The application doesn't have to relabel the socket to achieve that - we
handle that when we compute the label for the new connection socket
based in part on the label of the connecting request.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Socket and inode label consistency

[Trent Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]


On Aug 29, 2008, at 8:13 AM, Stephen Smalley wrote:

>
> On Thu, 2008-08-28 at 21:22 -0700, Casey Schaufler wrote:
>> Trent Jaeger wrote:
>>> ...
>>>>
>>>> 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.
>>>
>>
>> Sure, any service that wants to serve clients with a variety of  
>> labels.
>> The X server is an obvious candidate. A multi-label message bus.  
>> Label
>> aware sendmail. xinetd. Name services (the YP/NIS of the day).  
>> Anywhere
>> you want the label of the response to depend on the label of the  
>> request.
>> Yes, we're talking about Trusted Applications here, and specially  
>> coded
>> ones at that. Sometimes that's the best way.
>
> The application doesn't have to relabel the socket to achieve that  
> - we
> handle that when we compute the label for the new connection socket
> based in part on the label of the connecting request.

Yes, we prototyped this for xinetd (see SecureComm 2006 paper), and  
did not relabel the socket, but used the label of SA for the request.

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




[-- Attachment #2: Type: text/html, Size: 5464 bytes --]