From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port
Date: Thu, 18 Aug 2011 09:14:41 -0400 [thread overview]
Message-ID: <4E4D1041.5080400@tresys.com> (raw)
In-Reply-To: <4E4D0CBD.9060703@tresys.com>
On 8/18/2011 8:59 AM, Christopher J. PeBenito wrote:
> On 08/17/11 17:48, Paul Moore wrote:
>> On Wed, Aug 17, 2011 at 8:34 AM, Christopher J. PeBenito
>> <cpebenito@tresys.com> wrote:
>>> On 8/17/2011 7:50 AM, Daniel J Walsh wrote:
>>>> On 08/16/2011 11:58 PM, Sven Vermeulen wrote:
>>>>> On Tue, Aug 16, 2011 at 7:29 PM, Christopher J. PeBenito
>>>>> <cpebenito@tresys.com> wrote:
>>>>>> On 8/13/2011 3:11 PM, Sven Vermeulen wrote:
>>>>>>>
>>>>>>> To support NFS over UDP, we should allow rpcd_t to listen on a
>>>>>>> udp_socket.
>>>>>>
>>>>>> I'm confused. I don't see any UDP port binding for rpcd_t.
>>>>>
>>>>> It's pulled in through rpc_domain_template:
>>>>>
>>>>> rpc.te: rpc_domain_template(rpc) -->
>>>>> corenet_udp_bind_generic_port($1_t)
>>>>>
>>>>> To be honest, I'm also confused (but that's due to inexperience) why
>>>>> listen isn't part of create_socket_perms. If one creates a socket&
>>>>> binds to it, what cases are there that you don't listen on it? What
>>>>> is the need for create_stream_socket_perms?
>>>
>>> create_socket_perms is for connectionless sockets, and
>>> create_stream_socket_perms is for connection-oriented sockets (eg TCP and
>>> AF_UNIX/SOCK_STREAM [unix_stream_sockets]).
>>>
>>>>> Considering that, the patch might be best within the
>>>>> rpc_domain_template() template, considering that it currently reads:
>>>>>
>>>>> allow $1_t self:tcp_socket create_stream_socket_perms; allow $1_t
>>>>> self:udp_socket create_socket_perms;
>>>>>
>>>>> so the second line might then be best changed to
>>>>> create_stream_socket_perms. But I'll need to check first if this is
>>>>> needed for nfsd_t and gssd_t too.
>>>
>>>> You can probably dontaudit this call. You should not need to listen to
>>>> udp sockets, you could consider this a bug in the kernel for reporting it.
>>>>
>>>>
>>>> Doing a grep through Fedora policy I see
>>>>
>>>> ./kernel/domain.te: dontaudit domain self:udp_socket listen;
>>>>
>>>> Meaning we just added a rule to tell the system to ignore these bogus
>>>> AVC messages.
>>>
>>> It does sound like a bug, but I'd like to hear from the kernel guys. (cc'd)
>>
>> I think the problem you are seeing is that we do the *_socket:listen
>> access check in the kernel before we execute the protocol specific
>> listen() function - for obvious reasons. In this case of
>> tcp_socket:listen this is fine as TCP has a legitimate need for the
>> listen() call. However, in the case of udp_socket:listen this results
>> in some odd behavior since UDP does not support a listen call; in fact
>> the protocol specific listen() function simply returns -EOPNOTSUPP.
>>
>> If this was really problematic we could put some logic in the
>> socket_listen() hook but I'd like to avoid that if possible; it seems
>> much cleaner to just use a dontaudit rule in policy.
>
> Sigh. I can do that as Dan does in the Fedora policy, though I hate to
> waste kernel memory with rules that really shouldn't be needed.
Wait, why does dontaudit work? Wouldn't that change the return from
-EOPNOTSUPP to -EPERM, possibly causing other problems or am I just
overthinking it?
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
next prev parent reply other threads:[~2011-08-18 13:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-13 19:11 [refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port Sven Vermeulen
2011-08-16 19:29 ` Christopher J. PeBenito
[not found] ` <CAPzO=Nw_9arTkH53D+PCJR_2hg0XLtf_yEKv2LiGp8mHaU1zfw@mail.gmail.com>
2011-08-17 3:58 ` Sven Vermeulen
2011-08-17 11:50 ` Daniel J Walsh
2011-08-17 12:34 ` Christopher J. PeBenito
2011-08-17 21:48 ` Paul Moore
2011-08-18 12:59 ` Christopher J. PeBenito
2011-08-18 13:14 ` Christopher J. PeBenito [this message]
2011-08-18 13:52 ` Daniel J Walsh
-- strict thread matches above, loose matches on Subject: below --
2011-08-18 13:51 Paul Moore
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=4E4D1041.5080400@tresys.com \
--to=cpebenito@tresys.com \
--cc=refpolicy@oss.tresys.com \
/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.