From: Rongqing Li <rongqing.li@windriver.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@redhat.com>,
"selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>,
Eric Paris <eparis@parisplace.org>,
"Christopher J. PeBenito" <cpebenito@tresys.com>
Subject: Re: "netstat -Z" reimplementation
Date: Thu, 28 Jul 2011 11:00:30 +0800 [thread overview]
Message-ID: <4E30D0CE.4000702@windriver.com> (raw)
In-Reply-To: <1311774012.23346.16.camel@moss-pluto>
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.
next prev parent reply other threads:[~2011-07-28 3:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-27 9:28 "netstat -Z" reimplementation Rongqing Li
2011-07-27 10:51 ` Martin Christian
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 3:00 ` Rongqing Li [this message]
2011-07-28 2:58 ` Rongqing Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E30D0CE.4000702@windriver.com \
--to=rongqing.li@windriver.com \
--cc=cpebenito@tresys.com \
--cc=eparis@parisplace.org \
--cc=eparis@redhat.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.