Issue on getting security context of socket and message

Issue on getting security context of socket and message

[Park Lee]

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

Hi,
    In flask, as we know, sockets effectively serve as communication proxies for processes in the Flask control model. Consequently, sockets are labeled with the label of the creating process by default. Messages are associated with both the label of their sending socket and a separate message label. By default, this message label is the same as the sending socket label.
    Then how can we get the security context of socket and message respectively in linux kernel space and user space respectively (i.e. what functions and commands could we use to achieve our goal)? 
    And is messages here refer to packages in network?
    Thanks.


--
Best Regards,
Park Lee <parklee_sel@yahoo.com> 
 






			
---------------------------------
Do you Yahoo!?
 Check out the new Yahoo! Front Page. www.yahoo.com

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

Re: Issue on getting security context of socket and message

[Stephen Smalley]

On Tue, 2004-11-09 at 05:58, Park Lee wrote:
>     In flask, as we know, sockets effectively serve as communication
> proxies for processes in the Flask control model. Consequently,
> sockets are labeled with the label of the creating process by default.
> Messages are associated with both the label of their sending socket
> and a separate message label. By default, this message label is the
> same as the sending socket label.
>     Then how can we get the security context of socket and message
> respectively in linux kernel space and user space respectively (i.e.
> what functions and commands could we use to achieve our goal)? 
>     And is messages here refer to packages in network?

In the kernel, you can obtain the security context of a socket via the
security field of its associated inode.  Look at socket_has_perm() and
selinux_socket_sock_rcv_skb() in security/selinux/hooks.c for examples. 
Unix domain sockets can also use the sk_security field in the struct
sock for security state (e.g. peer SID), but INET sockets cannot safely
do so at present.  Remember that most of the LSM networking security
fields and hooks were rejected by the mainline kernel, so only limited
support exists in the current SELinux and there is no message labeling
at all.

Since sys_security was rejected by the mainline kernel, the extended
socket API of SELinux is not presently supported; we will ultimately
have to revisit it in the future when we have better motivating examples
of real applications that use it.  While fgetfilecon()->fgetxattr()
could conceivably export the security context of a local socket, that
would require implementing a fake xattr handler for the socket code;
alternative would be to implement it via getsockopt().  There is a
getpeercon(3) function in libselinux that allows you to get the context
of a peer for a Unix domain stream socket; this is internally
implemented via getsockopt().

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Issue on getting security context of socket and message

[Park Lee]

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

On Tue, 09 Nov 2004 at 10:39, Stephen Smalley wrote:
>       Remember that most of the LSM networking security
> fields and hooks were rejected by the mainline kernel, so only limited
> support exists in the current SELinux and there is no message  
> labeling at all.
 
       Thanks,
 
       Does that means that if we now want to integrate IPsec, we just can't add a 'package security context' into the security association?
      
        How can we get the SID of a socket and set SID and security context  to a socket respectively in linux kernel space and user space respectively (that is, what functions and commands could we use to achieve our goal)? 

         And,
         In <<Integrating Flexible Support for Security Policies into the Linux Operating System>> (February 2001), It says:
         "When the network component receives a message from the network, the SID of the message is initially set to a default message SID associated with the receiving network interface. This default message SID is computed by the security server.
         Each message is also associated with the SID of its source socket and the desired SID for its destination socket. By default, the desired SID for the destination socket of a message is set to the any socket initial SID. When a message is received from the network, the source socket SID of the message is initially set to the default message SID for the receiving network interface."
    
     But in initial_sid_contexts, it says something like this:
    "...
     # any_socket is no longer used.
     sid any_socket  system_u:object_r:unlabeled_t
     ...
     # netmsg is no longer used.
     sid netmsg system_u:object_r:unlabeled_t
     ..."
 
     Then, 
     1) Now, I know because there is no message labeling at all, netmsg is thus no longer used and when the network component  receives a message from the network, no SID will be set for the message. Am I right? 
     2) Is each message now still associated with the SID of its source socket and the desired SID for its destination socket? If it is, then what SID should be set to the destination socket associated with a message by default? 
     3) How to set the SID to the source socket and destination socket associated with the message based on a security context? need we transfer the security context to SID ourself and set it manually? and also how to get the SID and security context of them? 
 
      I appologize for so many questions.
 
      Thank you.
 


 


--
Best Regards,
Park Lee <parklee_sel@yahoo.com> 
 






			
---------------------------------
Do you Yahoo!?
 Check out the new Yahoo! Front Page. www.yahoo.com

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

Re: Issue on getting security context of socket and message

[Park Lee]

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

On Tue, 09 Nov 2004 at 10:39, Stephen Smalley wrote:
> In the kernel, you can obtain the security context of a socket via the
> security field of its associated inode.  Look at socket_has_perm() 
> and selinux_socket_sock_rcv_skb() in security/selinux/hooks.c for 
> examples. 

I'm now trying to do something on integrating IPsec with SELinux. Now I need to get the security context of a socket and the socket itself.
Would you please tell me further that when an outbound packet is going to be send, How can we get the struct socket itself (i.e. the socket that is related to the outbound packet. it refers that when we want to send the packet, we should first set up the socket )? 
 
And, in kernel-space, How can we transfer a SID to a security context? Is there any function can we use to achieve it?
 
Thank you.
 


--
Best Regards,
Park Lee <parklee_sel@yahoo.com> 
 






__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: Issue on getting security context of socket and message

[Stephen Smalley]

On Fri, 2004-11-26 at 13:50, Park Lee wrote:
> I'm now trying to do something on integrating IPsec with SELinux. Now
> I need to get the security context of a socket and the socket itself.
> Would you please tell me further that when an outbound packet is going
> to be send, How can we get the struct socket itself (i.e. the socket
> that is related to the outbound packet. it refers that when we want to
> send the packet, we should first set up the socket )?

Look at selinux_ip_postroute_last() in hooks.c.
 
> And, in kernel-space, How can we transfer a SID to a security context?
> Is there any function can we use to achieve it?

There is a security_sid_to_context() function; look at the existing
hooks.c code for usage.

But I don't think that this is likely going to be a productive use of
your time, as I think Trent Jaeger of IBM is already much further
along.  Likely better to wait for release of his patch, then see how you
can contribute to further development of it.  You might be better served
by looking into userspace issues, e.g. modifying racoon to deal with
security contexts.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Issue on getting security context of socket and message

[Stephen Smalley]

On Thu, 2005-03-10 at 02:33 -0800, Park Lee wrote:
> Does this mean that LSM doesn't provide any system 
> call for security-aware applications now? (While, in
> the past, it provided a security system call for such
> applications)
> 
> and,
> 
> Except for not supporting the extended socket API,
> Does SELinux now support other extended API (e.g.
> extended file API and extended process API)? 
> Does security server still provide system calls for
> security_aware applications?

This is discussed in several places, e.g.:
selinux-doc/PORTING
selinux-doc/module/syscall.sgml (in the latest selinux-doc, version
1.18)
http://www.nsa.gov/selinux/papers/module/x360.html
http://www.nsa.gov/selinux/papers/ols2003-selinux/text8.html

Please look at the existing documentation and mailing list archives
(more easily searchable via marc.theaimsgroup.com/?l=selinux) before
asking questions here.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Issue on getting security context of socket and message

[Park Lee]

On Tue, 09 Nov 2004 at 10:39, Stephen Smalley wrote:
> Since sys_security was rejected by the mainline 
> kernel, the extended socket API of SELinux is not 
> presently supported; 

Does this mean that LSM doesn't provide any system 
call for security-aware applications now? (While, in
the past, it provided a security system call for such
applications)

and,

Except for not supporting the extended socket API,
Does SELinux now support other extended API (e.g.
extended file API and extended process API)? 
Does security server still provide system calls for
security_aware applications?


Thank you.

Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

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