* Re: "netstat -Z" reimplementation
2011-07-27 12:09 ` Stephen Smalley
@ 2011-07-27 12:19 ` Daniel J Walsh
2011-07-27 13:37 ` Eric Paris
2011-07-28 2:58 ` Rongqing Li
2 siblings, 0 replies; 8+ messages in thread
From: Daniel J Walsh @ 2011-07-27 12:19 UTC (permalink / raw)
To: Stephen Smalley
Cc: Rongqing Li, selinux@tycho.nsa.gov, Eric Paris,
Christopher J. PeBenito
-----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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "netstat -Z" reimplementation
2011-07-27 12:09 ` Stephen Smalley
2011-07-27 12:19 ` Daniel J Walsh
@ 2011-07-27 13:37 ` Eric Paris
2011-07-27 13:40 ` Stephen Smalley
2011-07-28 2:58 ` Rongqing Li
2 siblings, 1 reply; 8+ messages in thread
From: Eric Paris @ 2011-07-27 13:37 UTC (permalink / raw)
To: Stephen Smalley
Cc: Rongqing Li, selinux@tycho.nsa.gov, Eric Paris,
Christopher J. PeBenito
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "netstat -Z" reimplementation
2011-07-27 13:37 ` Eric Paris
@ 2011-07-27 13:40 ` Stephen Smalley
2011-07-28 3:00 ` Rongqing Li
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Smalley @ 2011-07-27 13:40 UTC (permalink / raw)
To: Eric Paris
Cc: Rongqing Li, selinux@tycho.nsa.gov, Eric Paris,
Christopher J. PeBenito
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "netstat -Z" reimplementation
2011-07-27 13:40 ` Stephen Smalley
@ 2011-07-28 3:00 ` Rongqing Li
0 siblings, 0 replies; 8+ messages in thread
From: Rongqing Li @ 2011-07-28 3:00 UTC (permalink / raw)
To: Stephen Smalley
Cc: Eric Paris, selinux@tycho.nsa.gov, Eric Paris,
Christopher J. PeBenito
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: "netstat -Z" reimplementation
2011-07-27 12:09 ` Stephen Smalley
2011-07-27 12:19 ` Daniel J Walsh
2011-07-27 13:37 ` Eric Paris
@ 2011-07-28 2:58 ` Rongqing Li
2 siblings, 0 replies; 8+ messages in thread
From: Rongqing Li @ 2011-07-28 2:58 UTC (permalink / raw)
To: Stephen Smalley
Cc: selinux@tycho.nsa.gov, Eric Paris, Christopher J. PeBenito
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.
^ permalink raw reply [flat|nested] 8+ messages in thread