Skip to contentSkip to conversation

Allow NFS daemon to listen on an UDP port

PATCH New Sven Vermeulen 4 participants 9 messages Aug 13, 2011 – Aug 18, 2011 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

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

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.

---
 policy/modules/services/rpc.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
policy/modules/services/rpc.te +1 -0
index 62fca97..3c069d4 100644
@@ -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)
Signature · 1 line
1.7.3.4
#1 lore raw

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

Quoted 4 lines · 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.

I'm confused. I don't see any UDP port binding for rpcd_t.

Quoted 17 lines
---
  policy/modules/services/rpc.te |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
policy/modules/services/rpc.te +1 -0
index 62fca97..3c069d4 100644
@@ -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)
Signature · 3 lines
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

A message that is not in the archive (sent off-list or not yet received): CAPzO=Nw_9arTkH53D+PCJR_2hg0XLtf_yEKv2LiGp8mHaU1zfw@mail.gmail.com

#3 lore raw

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

Quoted 4 lines · Christopher J. PeBenito
Quoted 1 line · Sven Vermeulen

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.

#4 lore raw

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

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

Quoted 28 lines · Sven Vermeulen
Quoted 5 lines · Christopher J. PeBenito
Quoted 2 lines · Sven Vermeulen

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.

Quoted 6 lines

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

#5 lore raw

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

Quoted 21 lines · Daniel J Walsh

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

Quoted 17 lines · Sven Vermeulen
Quoted 5 lines · Christopher J. PeBenito
Quoted 2 lines · Sven Vermeulen

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]).

Quoted 14 lines
Quoted 9 lines

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.

Quoted 6 lines

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)

Signature · 3 lines
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
#6 lore raw

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

Quoted 45 lines · Christopher J. PeBenito
Quoted 25 lines · Daniel J Walsh

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

Quoted 20 lines · Sven Vermeulen
Quoted 7 lines · On Tue, Aug 16, 2011 at 7:29 PM, Christopher J. PeBenito…
Quoted 3 lines · Sven Vermeulen

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]).

Quoted 14 lines
Quoted 9 lines

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.

Quoted 8 lines
Quoted 6 lines

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.

Signature · 2 lines
paul moore
www.paul-moore.com
#7 lore raw

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

Quoted 58 lines · Paul Moore
Quoted 39 lines · Christopher J. PeBenito
Quoted 12 lines · Daniel J Walsh
Quoted 11 lines · Sven Vermeulen
Quoted 6 lines · Christopher J. PeBenito
Quoted 3 lines · Sven Vermeulen

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:

Quoted 7 lines
Quoted 7 lines

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]).

Quoted 14 lines
Quoted 9 lines

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.

Quoted 8 lines
Quoted 6 lines

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.

Quoted 3 lines

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.

Signature · 3 lines
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
#8 lore raw

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

Quoted 59 lines · Christopher J. PeBenito
Quoted 58 lines · Paul Moore
Quoted 39 lines · Christopher J. PeBenito
Quoted 12 lines · Daniel J Walsh
Quoted 11 lines · Sven Vermeulen
Quoted 6 lines · Christopher J. PeBenito
Quoted 3 lines · Sven Vermeulen

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:

Quoted 7 lines
Quoted 7 lines

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]).

Quoted 14 lines
Quoted 9 lines

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.

Quoted 8 lines
Quoted 6 lines

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.

Quoted 6 lines
Quoted 3 lines

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?

Signature · 3 lines
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
#9 lore raw

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

In reply to Christopher J. PeBenito

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

Quoted 66 lines · Christopher J. PeBenito
Quoted 65 lines · Paul Moore
Quoted 45 lines · Christopher J. PeBenito
Quoted 13 lines · Daniel J Walsh
Quoted 12 lines · Sven Vermeulen
Quoted 7 lines · Christopher J. PeBenito
Quoted 3 lines · Sven Vermeulen

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:

Quoted 8 lines
Quoted 8 lines

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]).

Quoted 18 lines
Quoted 10 lines

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

Quoted 8 lines
Quoted 5 lines

./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.

Quoted 7 lines
Quoted 3 lines

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