Restricting network communications of mounted filesystems

Restricting network communications of mounted filesystems

[Colin Powers]

Hi folks,

I have a question about the way network communications of mounted filesystems works with SELinux. I wonder if anyone could provide some insight or a link to somewhere with more information.

So let's say I have a RHEL6 machine with two network interfaces and I want to be very selective about which process can access which network interface.

I can use iptables SECMARK to label all traffic on eth0 as my_eth0_packet_t and all traffic on eth1 as my_eth1_packet_t, then grant send/recv permissions appropriately.

But let's say I want to be able to mount CIFS shares only using eth0. Does iptables SECMARK work in this scenario?
If so, what process is actually doing the network communications - what SELinux type do I need to grant permission to send/recv my_eth0_packet_t?
If not - how does the network comms work in this scenario and what are the options to achieve my goal of limiting traffic to eth0?

Cheers
Colin Powers

Re: Restricting network communications of mounted filesystems

[Brandon Whalen]

> On Aug 11, 2016, at 10:31 AM, Colin Powers <Colin.Powers@nexor.com> wrote:
> 
> Hi folks,
> 
> I have a question about the way network communications of mounted filesystems works with SELinux. I wonder if anyone could provide some insight or a link to somewhere with more information.

Look at section 2.21 of http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf. They cover the possibilities.

> 
> So let's say I have a RHEL6 machine with two network interfaces and I want to be very selective about which process can access which network interface.
> 
> I can use iptables SECMARK to label all traffic on eth0 as my_eth0_packet_t and all traffic on eth1 as my_eth1_packet_t, then grant send/recv permissions appropriately.
> 
> But let's say I want to be able to mount CIFS shares only using eth0. Does iptables SECMARK work in this scenario?
> If so, what process is actually doing the network communications - what SELinux type do I need to grant permission to send/recv my_eth0_packet_t?
> If not - how does the network comms work in this scenario and what are the options to achieve my goal of limiting traffic to eth0?
> 
> Cheers
> Colin Powers
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: Restricting network communications of mounted filesystems

[Stephen Smalley]

On 08/11/2016 10:31 AM, Colin Powers wrote:
> Hi folks,
> 
> I have a question about the way network communications of mounted filesystems works with SELinux. I wonder if anyone could provide some insight or a link to somewhere with more information.
> 
> So let's say I have a RHEL6 machine with two network interfaces and I want to be very selective about which process can access which network interface.
> 
> I can use iptables SECMARK to label all traffic on eth0 as my_eth0_packet_t and all traffic on eth1 as my_eth1_packet_t, then grant send/recv permissions appropriately.
> 
> But let's say I want to be able to mount CIFS shares only using eth0. Does iptables SECMARK work in this scenario?
> If so, what process is actually doing the network communications - what SELinux type do I need to grant permission to send/recv my_eth0_packet_t?
> If not - how does the network comms work in this scenario and what are the options to achieve my goal of limiting traffic to eth0?

Disclaimer: I don't really know how CIFS works, so take this with a
grain of salt.

Looking at the kernel code, fs/cifs/connect.c calls __sock_create(),
passing 1 for the last argument (kern), so its socket is created as a
kernel-internal socket rather than a user socket. The socket is
therefore labeled with the kernel SID/context rather than any particular
userspace process context, and can be reused for multiple processes.

The socket layer access control checks are completely skipped on such
sockets (sock_has_perm handles this case specially).  The packet layer
access control checks are still applied, but they will always be between
the kernel context and the packet context.

So I don't think you can enforce this restriction for CIFS traffic on a
per-process basis currently.

RE: Restricting network communications of mounted filesystems

[Colin Powers]

Thanks Stephen, that's really interesting.

I can solve my problem another way using a userspace process, it will just be a bit less convenient than using mount. I have a security need to prevent a compromised network process from accessing other network interfaces.

Is this scenario also true for other types of file shares that could be mounted, e.g. NFS, FTP (via curlftpfs)?

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: 11 August 2016 16:52
> To: Colin Powers <Colin.Powers@nexor.com>; SELinux@tycho.nsa.gov; Paul
> Moore <paul@paul-moore.com>
> Subject: Re: Restricting network communications of mounted filesystems
> 
> On 08/11/2016 10:31 AM, Colin Powers wrote:
> > Hi folks,
> >
> > I have a question about the way network communications of mounted
> filesystems works with SELinux. I wonder if anyone could provide some
> insight or a link to somewhere with more information.
> >
> > So let's say I have a RHEL6 machine with two network interfaces and I want
> to be very selective about which process can access which network interface.
> >
> > I can use iptables SECMARK to label all traffic on eth0 as my_eth0_packet_t
> and all traffic on eth1 as my_eth1_packet_t, then grant send/recv
> permissions appropriately.
> >
> > But let's say I want to be able to mount CIFS shares only using eth0. Does
> iptables SECMARK work in this scenario?
> > If so, what process is actually doing the network communications - what
> SELinux type do I need to grant permission to send/recv my_eth0_packet_t?
> > If not - how does the network comms work in this scenario and what are
> the options to achieve my goal of limiting traffic to eth0?
> 
> Disclaimer: I don't really know how CIFS works, so take this with a
> grain of salt.
> 
> Looking at the kernel code, fs/cifs/connect.c calls __sock_create(),
> passing 1 for the last argument (kern), so its socket is created as a
> kernel-internal socket rather than a user socket. The socket is
> therefore labeled with the kernel SID/context rather than any particular
> userspace process context, and can be reused for multiple processes.
> 
> The socket layer access control checks are completely skipped on such
> sockets (sock_has_perm handles this case specially).  The packet layer
> access control checks are still applied, but they will always be between
> the kernel context and the packet context.
> 
> So I don't think you can enforce this restriction for CIFS traffic on a
> per-process basis currently.
> 

Re: Restricting network communications of mounted filesystems

[Stephen Smalley]

On 08/12/2016 04:08 AM, Colin Powers wrote:
> Thanks Stephen, that's really interesting.
> 
> I can solve my problem another way using a userspace process, it will just be a bit less convenient than using mount. I have a security need to prevent a compromised network process from accessing other network interfaces.
> 
> Is this scenario also true for other types of file shares that could be mounted, e.g. NFS, FTP (via curlftpfs)?

Generally a socket is only created at mount time, and used for requests
from all clients, so it would be true for other remote filesystems as
well.  In some cases, the socket may be created by userspace (e.g.
likely the case for curlftpfs; might also be true for earlier versions
of NFS where the MOUNT protocol was performed by userspace) and
therefore be labeled with the context of the mounting process; in other
cases, the socket may be created and kept private to the kernel, and is
therefore labeled with the kernel context.  Regardless, the socket
context is not going to reflect the context of the individual clients
and therefore won't help with this kind of access control.