From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Thu, 18 Aug 2011 09:14:41 -0400 Subject: [refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port In-Reply-To: <4E4D0CBD.9060703@tresys.com> References: <20110813191106.GA19074@siphos.be> <4E4AC530.7000208@tresys.com> <4E4BAB20.1090007@redhat.com> <4E4BB56D.6000701@tresys.com> <4E4D0CBD.9060703@tresys.com> Message-ID: <4E4D1041.5080400@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.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 >> 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 >>>>> 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