All of lore.kernel.org
 help / color / mirror / Atom feed
* udp receive
@ 2002-07-03 13:56 Timothy Wood
  2002-07-03 14:08 ` Stephen Smalley
  2002-07-03 14:13 ` Stephen Smalley
  0 siblings, 2 replies; 5+ messages in thread
From: Timothy Wood @ 2002-07-03 13:56 UTC (permalink / raw)
  To: SELinux

I'm getting a recvfrom error for rpc.rquotad when I try to run nfs
services.  I can find a can_udp_send in the rpcd.te but I can not find
anything like can_udp_recv.  Is there anything like this that I need to
assign to the rpc.te in order to allow it to recv udp?

Timothy,


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: udp receive
  2002-07-03 13:56 udp receive Timothy Wood
@ 2002-07-03 14:08 ` Stephen Smalley
  2002-07-03 16:39   ` Timothy Wood
  2002-07-03 14:13 ` Stephen Smalley
  1 sibling, 1 reply; 5+ messages in thread
From: Stephen Smalley @ 2002-07-03 14:08 UTC (permalink / raw)
  To: Timothy Wood; +Cc: SELinux


On 3 Jul 2002, Timothy Wood wrote:

> I'm getting a recvfrom error for rpc.rquotad when I try to run nfs
> services.  I can find a can_udp_send in the rpcd.te but I can not find
> anything like can_udp_recv.  Is there anything like this that I need to
> assign to the rpc.te in order to allow it to recv udp?

I need more detail from the audit message, in particular the two types
from the scontext and tcontext fields. The can_udp_send macro
(defined in macros/global_macros.te) grants appropriate permissions for
the sender domain and the receiver domain, so you likely just need a
can_udp_send macro between the particular sender and receiver.  Of course,
this is only significant for loopback communication (or if you are using
the experimental labeled networking support for network communication),
since the packets are otherwise labeled based on the receiving network
interface and are handled by the can_network macro.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: udp receive
  2002-07-03 13:56 udp receive Timothy Wood
  2002-07-03 14:08 ` Stephen Smalley
@ 2002-07-03 14:13 ` Stephen Smalley
  1 sibling, 0 replies; 5+ messages in thread
From: Stephen Smalley @ 2002-07-03 14:13 UTC (permalink / raw)
  To: Timothy Wood; +Cc: SELinux


On 3 Jul 2002, Timothy Wood wrote:

> I'm getting a recvfrom error for rpc.rquotad when I try to run nfs
> services.  I can find a can_udp_send in the rpcd.te but I can not find
> anything like can_udp_recv.  Is there anything like this that I need to
> assign to the rpc.te in order to allow it to recv udp?

By the way, please note that the rpcd_t domain is simply a placeholder for
rpc daemons, and that you should really define an individual domain for
any rpc daemon that requires privilege (e.g. nfsd).  You should also
consider limiting this domain to true least privilege by removing
every_domain and only adding the bare minimum set of permissions needed
for operation.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: udp receive
  2002-07-03 14:08 ` Stephen Smalley
@ 2002-07-03 16:39   ` Timothy Wood
  2002-07-03 16:48     ` Stephen Smalley
  0 siblings, 1 reply; 5+ messages in thread
From: Timothy Wood @ 2002-07-03 16:39 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: SELinux

> I need more detail from the audit message, in particular the two types
> from the scontext and tcontext fields. 

avc:  denied  { recvfrom } for  pid=1791 exe=/usr/sbin/rpc.rquotad
saddr=127.0.0.1 source=696 daddr=127.0.0.1 dest=111 netif=lo
scontext=system_u:system_r:portmap_t tcontext=root:sysadm_r:sysadm_t
tclass=udp_socket


> The can_udp_send macro
> (defined in macros/global_macros.te) grants appropriate permissions for
> the sender domain and the receiver domain, so you likely just need a
> can_udp_send macro between the particular sender and receiver.  Of course,
> this is only significant for loopback communication (or if you are using

It looks to me like it's loopback between the rpc quota daemon and the
portmapper.

> By the way, please note that the rpcd_t domain is simply a placeholder
> for rpc daemons, and that you should really define an individual
> domain for any rpc daemon that requires privilege (e.g. nfsd).  You
> should also consider limiting this domain to true least privilege by
> removing every_domain and only adding the bare minimum set of
> permissions needed for operation.

Is there a template I could use or could someone please explain how to
go about creating a new domain?  I understand how to do some basic
modifications so far but I'm no expert yet.  Thanks


Timothy,



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: udp receive
  2002-07-03 16:39   ` Timothy Wood
@ 2002-07-03 16:48     ` Stephen Smalley
  0 siblings, 0 replies; 5+ messages in thread
From: Stephen Smalley @ 2002-07-03 16:48 UTC (permalink / raw)
  To: Timothy Wood; +Cc: SELinux


On 3 Jul 2002, Timothy Wood wrote:

> avc:  denied  { recvfrom } for  pid=1791 exe=/usr/sbin/rpc.rquotad
> saddr=127.0.0.1 source=696 daddr=127.0.0.1 dest=111 netif=lo
> scontext=system_u:system_r:portmap_t tcontext=root:sysadm_r:sysadm_t
> tclass=udp_socket
<snip>
> It looks to me like it's loopback between the rpc quota daemon and the
> portmapper.

In this case, the current process information is unreliable, since this
check is performed during network input processing.  You can see from the
pair of contexts that rpc.rquotad isn't truly the relevant process, since
neither context has the rpcd_t type.  What you really want to add is
can_udp_send($1_t, portmap_t) to macros/user_macros.te.

> Is there a template I could use or could someone please explain how to
> go about creating a new domain?  I understand how to do some basic
> modifications so far but I'm no expert yet.  Thanks

The Configuring the SELinux Policy report includes a very brief
introduction to creating new domains in the Creating a New Domain
subsection of the Customizing the Policy section.  The easiest approach is
to use one of the existing domains as a template.  You may want to use
Russell Coker's daemon_domain macro (in global_macros.te) to get started.
The recently posted samba domains were reworked to use that macro, as you
can see from Ryan Bergauer's postings.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-07-03 16:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-07-03 13:56 udp receive Timothy Wood
2002-07-03 14:08 ` Stephen Smalley
2002-07-03 16:39   ` Timothy Wood
2002-07-03 16:48     ` Stephen Smalley
2002-07-03 14:13 ` Stephen Smalley

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.