[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Sven Vermeulen]

Support for binding to the UDP port is already applied to the tree, but I guess
this little patch fell off the stack ;-)

To support NFS over UDP, we should allow rpcd_t to listen on a udp_socket.

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 policy/modules/services/rpc.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/policy/modules/services/rpc.te b/policy/modules/services/rpc.te
index 62fca97..3c069d4 100644
--- a/policy/modules/services/rpc.te
+++ b/policy/modules/services/rpc.te
@@ -61,6 +61,7 @@ files_mountpoint(var_lib_nfs_t)
 allow rpcd_t self:capability { sys_admin chown dac_override setgid setuid };
 allow rpcd_t self:process { getcap setcap };
 allow rpcd_t self:fifo_file rw_fifo_file_perms;
+allow rpcd_t self:udp_socket { listen };
 
 allow rpcd_t rpcd_var_run_t:dir setattr;
 manage_files_pattern(rpcd_t, rpcd_var_run_t, rpcd_var_run_t)
-- 
1.7.3.4

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Christopher J. PeBenito]

On 8/13/2011 3:11 PM, Sven Vermeulen wrote:
> Support for binding to the UDP port is already applied to the tree, but I guess
> this little patch fell off the stack ;-)
>
> 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.

> Signed-off-by: Sven Vermeulen<sven.vermeulen@siphos.be>
> ---
>   policy/modules/services/rpc.te |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/services/rpc.te b/policy/modules/services/rpc.te
> index 62fca97..3c069d4 100644
> --- a/policy/modules/services/rpc.te
> +++ b/policy/modules/services/rpc.te
> @@ -61,6 +61,7 @@ files_mountpoint(var_lib_nfs_t)
>   allow rpcd_t self:capability { sys_admin chown dac_override setgid setuid };
>   allow rpcd_t self:process { getcap setcap };
>   allow rpcd_t self:fifo_file rw_fifo_file_perms;
> +allow rpcd_t self:udp_socket { listen };
>
>   allow rpcd_t rpcd_var_run_t:dir setattr;
>   manage_files_pattern(rpcd_t, rpcd_var_run_t, rpcd_var_run_t)


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

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Sven Vermeulen]

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?

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.

Wkr,
 Sven Vermeulen

PS Sorry Christopher for remailing, got the wrong To again. Heh.

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Daniel J Walsh]

-----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?
> 
> 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.
> 
> Wkr, Sven Vermeulen
> 
> PS Sorry Christopher for remailing, got the wrong To again. Heh. 
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com 
> http://oss.tresys.com/mailman/listinfo/refpolicy
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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5LqyAACgkQrlYvE4MpobNvGQCg4bdESvvoOGS4P34oK6nebwmo
VbEAoLLvJDbWzbj2svshzJqdh94xylJz
=SFad
-----END PGP SIGNATURE-----

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Christopher J. PeBenito]

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

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Paul Moore]

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:
>>
>> -----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)

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.

-- 
paul moore
www.paul-moore.com

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Christopher J. PeBenito]

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.

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

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Christopher J. PeBenito]

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

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/18/2011 08: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.
> 
If you want to save kernel memory, remove all policy that uses the "-"
construct

port_type -reserved_port_type;

file_type -shadow_t;

Cause tens of thousands of rules to be added to policy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5NGREACgkQrlYvE4MpobNljwCgxAfbCOhRumNpEG2BHfvcFUUF
7oAAoM+53R/ycw+5ennreKVOrCOiEITD
=2Vtu
-----END PGP SIGNATURE-----

[refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port

[Paul Moore]

The return value should be the same regardless of audit/dontaudit.

--
paul moore
www.paul-moore.com

-original message-
Subject: Re: [refpolicy] [PATCH 1/1] Allow NFS daemon to listen on an UDP port
From: "Christopher J. PeBenito" <cpebenito@tresys.com>
Date: 08/18/2011 6:14 AM

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