All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 17 Aug 2011 08:34:53 -0400	[thread overview]
Message-ID: <4E4BB56D.6000701@tresys.com> (raw)
In-Reply-To: <4E4BAB20.1090007@redhat.com>

On 8/17/2011 7:50 AM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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)

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

  reply	other threads:[~2011-08-17 12:34 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 [this message]
2011-08-17 21:48           ` Paul Moore
2011-08-18 12:59             ` Christopher J. PeBenito
2011-08-18 13:14               ` Christopher J. PeBenito
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=4E4BB56D.6000701@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.