Re: Policy module to allow a domain transition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 16 Mar 2020, Dominick Grift wrote:

> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes:
> 
> > If this is not the the right forum for this discussion, please redirect
> > me to some place more appropriate.  Where to go for good advice on the
> > trickier details of selinux is not obvious.
> >
> > The setting is CentOS 8.1.  I'm running tcpserver as a systemd service.  
> > tcpserver is a general-purpose Internet (actually TCP) service 
> > dispatcher, rather like inetd.
> >
> > In this case, I'm trying to use tcpserver as an entryway to sshd.  It 
> > works fine when selinux is in permissive mode but fails in enforcing 
> > mode.  According to audit.log, the error is:
> >
> > type=AVC msg=audit(1584123331.011:167): avc:  denied  { dyntransition } for  pid=2002 comm="sshd" scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=1
> >
> > I take this to mean that tcpserver runs in the unconfined_service_t 
> > domain (confirmed by ps -Z), that when it execs the sshd program it 
> > doesn't make the transition to the sshd_t domain, and consequently sshd 
> > is prevented from doing what it wants.
> >
> > audit2allow's recommendation is:
> >
> > 	allow unconfined_service_t unconfined_t:process dyntransition;
> >
> > which probably would work, but it seems like treating the symptom
> > rather than the disease, not to mention opening up a fairly large
> > security hole.  I'd like something a little more specific, particularly
> > since I want to run one or two other services under tcpserver in
> > addition to sshd.
> >
> > Probably the best approach would be to create a new tcpserver_t type
> > with all the appropriate policies, but that's beyond my current skill.  
> > Would it make sense to create a policy module that would simply allow
> > unconfined_service_t to transition to sshd_t?
> >
> > And what would the source for such a policy module look like?  The 
> > impression I get is something like:
> >
> > 	allow unconfined_service_t sshd_exec_t:file { execute
> > 		execute_no_trans getattr ioctl map open read };
> 
> That would be redundant. unconfined_service_t already has broad access
> and from a unconfined_service_t perspective you just need to tell
> selinux what to do:
> 
> type_transition unconfined_service_t sshd_exec_t:process sshd_t;
> 
> That will tell selinux that processes types should transition from
> unconfined_service_t to sshd_t when processes with type
> unconfined_service_t execute files with type sshd_exec_t.
> 
> When you do this and try it out then some avc denials will likely
> surface regarding access that sshd_t processes may need to
> unconfined_service_t processes. (for example sending a child terminated
> signal, but possibly others as well)

Yes, I see what you mean.  I'm getting AVC violations because sshd 
isn't supposed to perform getattr and setopt actions on a tcp_socket of 
type unconfined_service_t, which is what it gets when it inherits a 
socket from tcpserver instead of opening the socket itself.

It looks like the tcp_socket needs to undergo a type transition along
with the process.  Is there any way to express this?

Alan Stern

PS: There appears to be a bunch of redundant rules relating sshd_t and 
tcp_socket in the system's policy database.  Part of the output from 
sesearch says:

allow sshd_t sshd_t:tcp_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write };
allow sshd_t sshd_t:tcp_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write }; [ nis_enabled ]:True
allow sshd_t sshd_t:tcp_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write }; [ nis_enabled ]:True
allow sshd_t sshd_t:tcp_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write }; [ authlogin_nsswitch_use_ldap ]:True
allow sshd_t sshd_t:tcp_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write }; [ kerberos_enabled ]:True
allow sshd_t sshd_t:tcp_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write }; [ kerberos_enabled ]:True
allow sshd_t sshd_t:tcp_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write }; [ kerberos_enabled ]:True
allow sshd_t tcpd_t:tcp_socket { append bind connect getattr getopt ioctl lock read setattr setopt shutdown write }; [ ssh_use_tcpd ]:True

Don't all those boolean-controlled rules just allow things that are
already allowed anyway?  Or do they override the first rule, forbidding
some of the things it allows (which seems contrary to the idea of using
these booleans to allow things that wouldn't normally be allowed)?

PPS: Is there any document anywhere that explains all the details
needed to understand and create selinux policies?  I see individual
items covered piecemeal in the wiki pages at selinuxproject.org, but no
organized whole.  Certainly nothing that would enable the reader to
formulate a strategy for solving the problem I encountered.

As just one example, is there a complete listing of the syntax
required/accepted by checkmodule in a .te file?




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux