"netstat -Z" reimplementation

"netstat -Z" reimplementation

[Rongqing Li]

SELinux folks, Stephen:

I have some thoughts about reimplementation of 'netstat -Z', but I do
not know if it is valuable, or if there are other risks. Could you
evaluate my implementation, or give me your valuable advice?

1. From kernel, print the socket labels to tcp, udp, raw, unix
files under /proc/net/.

Now the /proc/net/tcp /proc/net/udp ... include many socket's
information, like local address, remote address, inode, I think we can
put the socket's security context to these files.

To avoid to expose these information to non-privileged users, security
checking should be done when expose the socket security context to procfs.

2. reimplementation the "netstat -Z", "netstat -Z" will first parse the
security context from procfs's tcp, udp, raw files, and get the security
context, if this step fails, "netstat -Z" will try as legacy method.


If this implementation could be accepted by mainstream, netstat could
print the correct socket label even if the type_transition has been
happen on socket, or application changes socket labels by setting
/proc/self/attr/sockcreate.


Do you think it is valuable?

Thanks

-- 
Best Reagrds,
Roy | RongQing Li
-------------------------------------------------------------
WIND RIVER Beijing | China Development Center
Phone: +86-10-6483-5025, Cell: +86-135-2202-9864, Fax: +86-10-6479-0367


--
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: "netstat -Z" reimplementation

[Martin Christian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Rongqing,

we would appreciate such an extension to netstat. We shortly had a
problem where it had helped if we could have see the labels of unix
domain sockets.

I'll try to help as much as possible (considering our project constraints).

Regards,

Martin.


Am 27.07.2011 11:28, schrieb Rongqing Li:
> SELinux folks, Stephen:
> 
> I have some thoughts about reimplementation of 'netstat -Z', but I do
> not know if it is valuable, or if there are other risks. Could you
> evaluate my implementation, or give me your valuable advice?
> 
> 1. From kernel, print the socket labels to tcp, udp, raw, unix
> files under /proc/net/.
> 
> Now the /proc/net/tcp /proc/net/udp ... include many socket's
> information, like local address, remote address, inode, I think we can
> put the socket's security context to these files.
> 
> To avoid to expose these information to non-privileged users, security
> checking should be done when expose the socket security context to procfs.
> 
> 2. reimplementation the "netstat -Z", "netstat -Z" will first parse the
> security context from procfs's tcp, udp, raw files, and get the security
> context, if this step fails, "netstat -Z" will try as legacy method.
> 
> 
> If this implementation could be accepted by mainstream, netstat could
> print the correct socket label even if the type_transition has been
> happen on socket, or application changes socket labels by setting
> /proc/self/attr/sockcreate.
> 
> 
> Do you think it is valuable?
> 
> Thanks
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOL+2uAAoJEGpTkDITRjmoT3EH/j6Egi1tg9FUqa3nELZKepQY
lIOvvlHMJyboNlaisHkLS+MeMgO32mKfwiO2Vq4MNNFFHgEHt1J2BoIaNUU/D07K
KVNvfEVcD3jV/B2vpqM6ugUjrzmxmueDhdYvnG2l4nTPVxnN+irZ60ECcpgW7b2h
YZ5HKRAQ4MJkkCZacX03g3YX5J7inI3GU6eXUsim1/g54vdyCTRHn6M3AIizYozt
+7Ey60CdgPBKHr8MnwZVgkC21zkZS0E/8ZOYFxYPKATBbdlINxOWG2i4mUTp9eJE
svK/IMqJ4DXEg6RfGNwEB/KEms0W5ExOW/0M2TqoaukJBlLjZ20g4tQWZSVMVkg=
=zm+N
-----END PGP SIGNATURE-----

--
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: "netstat -Z" reimplementation

[Stephen Smalley]

On Wed, 2011-07-27 at 17:28 +0800, Rongqing Li wrote:
> SELinux folks, Stephen:
> 
> I have some thoughts about reimplementation of 'netstat -Z', but I do
> not know if it is valuable, or if there are other risks. Could you
> evaluate my implementation, or give me your valuable advice?
> 
> 1. From kernel, print the socket labels to tcp, udp, raw, unix
> files under /proc/net/.
> 
> Now the /proc/net/tcp /proc/net/udp ... include many socket's
> information, like local address, remote address, inode, I think we can
> put the socket's security context to these files.
> 
> To avoid to expose these information to non-privileged users, security
> checking should be done when expose the socket security context to procfs.

We can already control the ability to read /proc/net files by labeling
them via genfscon statements and then writing policy accordingly.  Do we
think exposing the (raw) security context is any more of a concern than
the rest of the information in the file?

Can we add a field to those files without breaking compatibility with
existing userspace?

> 2. reimplementation the "netstat -Z", "netstat -Z" will first parse the
> security context from procfs's tcp, udp, raw files, and get the security
> context, if this step fails, "netstat -Z" will try as legacy method.

It should only fall back to the legacy method if the context is not
present in the file; if there is any other reason for failure (e.g.
permission denied to /proc/net/tcp), then we presumably want netstat -Z
to fail rather than report a possibly incorrect result.

> If this implementation could be accepted by mainstream, netstat could
> print the correct socket label even if the type_transition has been
> happen on socket, or application changes socket labels by setting
> /proc/self/attr/sockcreate.
> 
> 
> Do you think it is valuable?

Yes, I think it would be useful.

-- 
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: "netstat -Z" reimplementation

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/27/2011 08:09 AM, Stephen Smalley wrote:
> On Wed, 2011-07-27 at 17:28 +0800, Rongqing Li wrote:
>> SELinux folks, Stephen:
>> 
>> I have some thoughts about reimplementation of 'netstat -Z', but I
>> do not know if it is valuable, or if there are other risks. Could
>> you evaluate my implementation, or give me your valuable advice?
>> 
>> 1. From kernel, print the socket labels to tcp, udp, raw, unix 
>> files under /proc/net/.
>> 
>> Now the /proc/net/tcp /proc/net/udp ... include many socket's 
>> information, like local address, remote address, inode, I think we
>> can put the socket's security context to these files.
>> 
>> To avoid to expose these information to non-privileged users,
>> security checking should be done when expose the socket security
>> context to procfs.
> 
> We can already control the ability to read /proc/net files by
> labeling them via genfscon statements and then writing policy
> accordingly.  Do we think exposing the (raw) security context is any
> more of a concern than the rest of the information in the file?
> 
> Can we add a field to those files without breaking compatibility
> with existing userspace?
> 
>> 2. reimplementation the "netstat -Z", "netstat -Z" will first parse
>> the security context from procfs's tcp, udp, raw files, and get the
>> security context, if this step fails, "netstat -Z" will try as
>> legacy method.
> 
> It should only fall back to the legacy method if the context is not 
> present in the file; if there is any other reason for failure (e.g. 
> permission denied to /proc/net/tcp), then we presumably want netstat
> -Z to fail rather than report a possibly incorrect result.
> 
>> If this implementation could be accepted by mainstream, netstat
>> could print the correct socket label even if the type_transition
>> has been happen on socket, or application changes socket labels by
>> setting /proc/self/attr/sockcreate.
>> 
>> 
>> Do you think it is valuable?
> 
> Yes, I think it would be useful.
> 


I agree, having netstat return correct data, would be a benefit.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4wAlcACgkQrlYvE4MpobOm9gCgnnLAAHtqNB4OCgzIO1XZtgD9
w8YAn1Mvj4s7/V8TK0TklXhEKReF/BFL
=IN7y
-----END PGP SIGNATURE-----

--
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: "netstat -Z" reimplementation

[Eric Paris]

On 07/27/2011 08:09 AM, Stephen Smalley wrote:
> On Wed, 2011-07-27 at 17:28 +0800, Rongqing Li wrote:
>> SELinux folks, Stephen:
>>
>> I have some thoughts about reimplementation of 'netstat -Z', but I do
>> not know if it is valuable, or if there are other risks. Could you
>> evaluate my implementation, or give me your valuable advice?
>>
>> 1. From kernel, print the socket labels to tcp, udp, raw, unix
>> files under /proc/net/.
>>
>> Now the /proc/net/tcp /proc/net/udp ... include many socket's
>> information, like local address, remote address, inode, I think we can
>> put the socket's security context to these files.
>>
>> To avoid to expose these information to non-privileged users, security
>> checking should be done when expose the socket security context to procfs.
> 
> We can already control the ability to read /proc/net files by labeling
> them via genfscon statements and then writing policy accordingly.  Do we
> think exposing the (raw) security context is any more of a concern than
> the rest of the information in the file?
> 
> Can we add a field to those files without breaking compatibility with
> existing userspace?

I tried once in the past and was told that no, I was not allowed to add
fields (seemed pretty stupid to me at the time and I don't remember if
the person who told me that actually knew what they were talking about)

I believe I was told (and you should believe that my memory for things
more than 10 minutes old stinks and this was about 4 years ago) that I
was supposed to use "tcp_diag" instead.  I never figured out what that
was, so I never got the patch in...

Just figured you should know up front....

-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: "netstat -Z" reimplementation

[Stephen Smalley]

On Wed, 2011-07-27 at 09:37 -0400, Eric Paris wrote:
> On 07/27/2011 08:09 AM, Stephen Smalley wrote:
> > On Wed, 2011-07-27 at 17:28 +0800, Rongqing Li wrote:
> >> SELinux folks, Stephen:
> >>
> >> I have some thoughts about reimplementation of 'netstat -Z', but I do
> >> not know if it is valuable, or if there are other risks. Could you
> >> evaluate my implementation, or give me your valuable advice?
> >>
> >> 1. From kernel, print the socket labels to tcp, udp, raw, unix
> >> files under /proc/net/.
> >>
> >> Now the /proc/net/tcp /proc/net/udp ... include many socket's
> >> information, like local address, remote address, inode, I think we can
> >> put the socket's security context to these files.
> >>
> >> To avoid to expose these information to non-privileged users, security
> >> checking should be done when expose the socket security context to procfs.
> > 
> > We can already control the ability to read /proc/net files by labeling
> > them via genfscon statements and then writing policy accordingly.  Do we
> > think exposing the (raw) security context is any more of a concern than
> > the rest of the information in the file?
> > 
> > Can we add a field to those files without breaking compatibility with
> > existing userspace?
> 
> I tried once in the past and was told that no, I was not allowed to add
> fields (seemed pretty stupid to me at the time and I don't remember if
> the person who told me that actually knew what they were talking about)
> 
> I believe I was told (and you should believe that my memory for things
> more than 10 minutes old stinks and this was about 4 years ago) that I
> was supposed to use "tcp_diag" instead.  I never figured out what that
> was, so I never got the patch in...
> 
> Just figured you should know up front....

Ok, so perhaps he should ask on linux-netdev about how/where to add such
information before he spends too much time on it?

-- 
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: "netstat -Z" reimplementation

[Rongqing Li]

On 07/27/2011 08:09 PM, Stephen Smalley wrote:
> On Wed, 2011-07-27 at 17:28 +0800, Rongqing Li wrote:
>> SELinux folks, Stephen:
>>
>> I have some thoughts about reimplementation of 'netstat -Z', but I do
>> not know if it is valuable, or if there are other risks. Could you
>> evaluate my implementation, or give me your valuable advice?
>>
>> 1. From kernel, print the socket labels to tcp, udp, raw, unix
>> files under /proc/net/.
>>
>> Now the /proc/net/tcp /proc/net/udp ... include many socket's
>> information, like local address, remote address, inode, I think we can
>> put the socket's security context to these files.
>>
>> To avoid to expose these information to non-privileged users, security
>> checking should be done when expose the socket security context to procfs.
>
> We can already control the ability to read /proc/net files by labeling
> them via genfscon statements and then writing policy accordingly.  Do we
> think exposing the (raw) security context is any more of a concern than
> the rest of the information in the file?
>
> Can we add a field to those files without breaking compatibility with
> existing userspace?
>

Currently, if a user can access /proc/net/tcp, this user can get tcp socket
all information, I think this maybe a error.

Like below case:
-------------------------------------------------------
# id -Z
root:sysadm_r:sysadm_t:s0-s15:c0.c1023
#
# netstat -Za |grep "dev/log"
unix  2      [ ACC ]     STREAM     LISTENING     7263   508/syslog-ng 
system_u:system_r:syslogd_t:s15:c0.c1023          /dev/log
#
-------------------------------------------------------

This control can be implemented when kernel print this information to 
kernel.

-Roy

>> 2. reimplementation the "netstat -Z", "netstat -Z" will first parse the
>> security context from procfs's tcp, udp, raw files, and get the security
>> context, if this step fails, "netstat -Z" will try as legacy method.
>
> It should only fall back to the legacy method if the context is not
> present in the file; if there is any other reason for failure (e.g.
> permission denied to /proc/net/tcp), then we presumably want netstat -Z
> to fail rather than report a possibly incorrect result.
>
>> If this implementation could be accepted by mainstream, netstat could
>> print the correct socket label even if the type_transition has been
>> happen on socket, or application changes socket labels by setting
>> /proc/self/attr/sockcreate.
>>
>>
>> Do you think it is valuable?
>
> Yes, I think it would be useful.
>

-- 
Best Reagrds,
Roy | RongQing Li
-------------------------------------------------------------
WIND RIVER Beijing | China Development Center
Phone: +86-10-6483-5025, Cell: +86-135-2202-9864, Fax: +86-10-6479-0367

--
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: "netstat -Z" reimplementation

[Rongqing Li]

On 07/27/2011 09:40 PM, Stephen Smalley wrote:
> On Wed, 2011-07-27 at 09:37 -0400, Eric Paris wrote:
>> On 07/27/2011 08:09 AM, Stephen Smalley wrote:
>>> On Wed, 2011-07-27 at 17:28 +0800, Rongqing Li wrote:
>>>> SELinux folks, Stephen:
>>>>
>>>> I have some thoughts about reimplementation of 'netstat -Z', but I do
>>>> not know if it is valuable, or if there are other risks. Could you
>>>> evaluate my implementation, or give me your valuable advice?
>>>>
>>>> 1. From kernel, print the socket labels to tcp, udp, raw, unix
>>>> files under /proc/net/.
>>>>
>>>> Now the /proc/net/tcp /proc/net/udp ... include many socket's
>>>> information, like local address, remote address, inode, I think we can
>>>> put the socket's security context to these files.
>>>>
>>>> To avoid to expose these information to non-privileged users, security
>>>> checking should be done when expose the socket security context to procfs.
>>>
>>> We can already control the ability to read /proc/net files by labeling
>>> them via genfscon statements and then writing policy accordingly.  Do we
>>> think exposing the (raw) security context is any more of a concern than
>>> the rest of the information in the file?
>>>
>>> Can we add a field to those files without breaking compatibility with
>>> existing userspace?
>>
>> I tried once in the past and was told that no, I was not allowed to add
>> fields (seemed pretty stupid to me at the time and I don't remember if
>> the person who told me that actually knew what they were talking about)
>>
>> I believe I was told (and you should believe that my memory for things
>> more than 10 minutes old stinks and this was about 4 years ago) that I
>> was supposed to use "tcp_diag" instead.  I never figured out what that
>> was, so I never got the patch in...
>>
>> Just figured you should know up front....
>
> Ok, so perhaps he should ask on linux-netdev about how/where to add such
> information before he spends too much time on it?
>
Hi SElinux folks:

Thank you very much.
I will discuss this with linux-netdev, and report the feedback and progress.


-Roy
-- 
Best Reagrds,
Roy | RongQing Li
-------------------------------------------------------------
WIND RIVER Beijing | China Development Center
Phone: +86-10-6483-5025, Cell: +86-135-2202-9864, Fax: +86-10-6479-0367

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