Policy module to allow a domain transition

Policy module to allow a domain transition

[Alan Stern]

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

basically just a copy an existing policy for inetd_t and 
sshd_exec_t.  Is that the right way to go about this?  Is there 
something better?

Thank you,

Alan Stern

Re: Policy module to allow a domain transition

[Dominick Grift]

Alan Stern <stern@rowland.harvard.edu> 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)

>
> basically just a copy an existing policy for inetd_t and 
> sshd_exec_t.  Is that the right way to go about this?  Is there 
> something better?
>
> Thank you,
>
> Alan Stern
>

-- 
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: Policy module to allow a domain transition

[peter enderborg]

On 3/16/20 5:04 PM, Alan Stern wrote:
> 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 };
>
> basically just a copy an existing policy for inetd_t and 
> sshd_exec_t.  Is that the right way to go about this?  Is there 
> something better?

The hole idea with MAC is that you should explicit declare what is allowed.

Starting with anything unconfined is a bad idea for anything that is seen
from the internet. If you do it for the security your tcpserver should have it's own
domain that is not unconfined. And then you can give rules on what it is allowed
to start.  So you need to create a tcpservice_service_t, so your rule should be

allow tcpservice_service_t sshd_exec_t:file { execute
		execute_no_trans getattr ioctl map open read };

/* execute_no_trans is probably not what you want */

 But you do NOT want

allow tcpservice_service_t unconfined_t:process dyntransition;


On fedora it would be like:

allow tcpservice_service_t sshd_t:process dyntransition;

and sshd is then allowed to create unconfined shell or what ever.
 

> Thank you,
>
> Alan Stern
>
>

Re: Policy module to allow a domain transition

[Dominick Grift]

peter enderborg <peter.enderborg@sony.com> writes:

> On 3/16/20 5:04 PM, Alan Stern wrote:
>> 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 };
>>
>> basically just a copy an existing policy for inetd_t and 
>> sshd_exec_t.  Is that the right way to go about this?  Is there 
>> something better?
>
> The hole idea with MAC is that you should explicit declare what is allowed.

I do not agree with that. The idea of MAC is Mandatory (centralized) Access
Control. The idea of SELinux is "Flexible MAC". Least privilege is an option.

>
> Starting with anything unconfined is a bad idea for anything that is seen
> from the internet. If you do it for the security your tcpserver should have it's own
> domain that is not unconfined. And then you can give rules on what it is allowed
> to start.  So you need to create a tcpservice_service_t, so your rule should be

Op made it clear that this is not an option right now. Also keep in mind
that tcp server listens on behalf of sshd which will be confined once
SELinux transitions tcpserver from unconfined_service_t to sshd_t as per
my example earlier.

It is not ideal, granted, but there are subtile details to
consider. Things are either black or white.

>
> allow tcpservice_service_t sshd_exec_t:file { execute
> 		execute_no_trans getattr ioctl map open read };
>
> /* execute_no_trans is probably not what you want */
>
>  But you do NOT want
>
> allow tcpservice_service_t unconfined_t:process dyntransition;
>
>
> On fedora it would be like:
>
> allow tcpservice_service_t sshd_t:process dyntransition;
>
> and sshd is then allowed to create unconfined shell or what ever.
>  
>
>> Thank you,
>>
>> Alan Stern
>>
>>
>

-- 
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: Policy module to allow a domain transition

[Alan Stern]

On Mon, 16 Mar 2020, Dominick Grift wrote:

> Alan Stern <stern@rowland.harvard.edu> 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?

Re: Policy module to allow a domain transition

[Dominick Grift]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Mon, 16 Mar 2020, Dominick Grift wrote:
>
>> Alan Stern <stern@rowland.harvard.edu> 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?

tcpd would have to grow selinux awareness and do that manually using the
setsockcreate() functionality provided by libselinux.

systemd does this with its socket activation functionality.

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

Yes, inefficient 

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

selinuxproject.org documents almost the full policy language (the docs
there arent maintained all that well)

Another great documentation is:
https://github.com/SELinuxProject/selinux/tree/master/secilc/docs
This is for the CIL, but can be useful nonetheless to give an idea of
the possibilities.

Some aspects that are interesting:

transitions: manual, automatic and dynamic
role based access control: user role, role type and role allow rules
policy constraints
attributes vs. identifiers
security classes and access vector permissions (access vectors)

>

-- 
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: Policy module to allow a domain transition

[Alan Stern]

On Tue, 17 Mar 2020, Dominick Grift wrote:

> Alan Stern <stern@rowland.harvard.edu> writes:
> 
> > On Mon, 16 Mar 2020, Dominick Grift wrote:
> >
> >> Alan Stern <stern@rowland.harvard.edu> 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?
> 
> tcpd would have to grow selinux awareness and do that manually using the
> setsockcreate() functionality provided by libselinux.
> 
> systemd does this with its socket activation functionality.

All right, so rather than try to change the programs, I added the
following TE rule:

allow sshd_t unconfined_service_t:tcp_socket { getattr setopt };

With that, sshd under tcpserver worked okay in permissive mode, with no
AVC notices in audit.log.  But when I changed to enforcing mode, the
program failed for no apparent reason (and again, no AVC messages).  
The remote system merely reported "Connection reset by peer".  Any idea
what's wrong?

Alan Stern

Re: Policy module to allow a domain transition

[Dominick Grift]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Tue, 17 Mar 2020, Dominick Grift wrote:
>
>> Alan Stern <stern@rowland.harvard.edu> writes:
>> 
>> > On Mon, 16 Mar 2020, Dominick Grift wrote:
>> >
>> >> Alan Stern <stern@rowland.harvard.edu> 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?
>> 
>> tcpd would have to grow selinux awareness and do that manually using the
>> setsockcreate() functionality provided by libselinux.
>> 
>> systemd does this with its socket activation functionality.
>
> All right, so rather than try to change the programs, I added the
> following TE rule:
>
> allow sshd_t unconfined_service_t:tcp_socket { getattr setopt };
>
> With that, sshd under tcpserver worked okay in permissive mode, with no
> AVC notices in audit.log.  But when I changed to enforcing mode, the
> program failed for no apparent reason (and again, no AVC messages).  
> The remote system merely reported "Connection reset by peer".  Any idea
> what's wrong?

You can run `semodule -DB` to make SELinux more verbose. (use `semodule
-B` to make SELinux less verbose when youre done)

My guess is that some socket accesses are silently blocked. Is a long
story but the socket read and write accessed might be silently blocked
because they are often false positives caused by leaked file
descriptors.

In this case the read write on tcp_socket would be legit and would need
to be allowed.

So if you do a `semodule -DB` then reproduce a login, then look for avc
denials related to sshd_t, unconfined_service_t and tcp_sockets (my bet
is on read and write) but eventually sshd obviously also needs to
"accept" connections as well. In other words: "tcp_socket { getattr
setopt }" is incomplete but the next access attempts (read/write) are
silently blocked by policy and so without that it cannot do its job.

>
> Alan Stern
>

-- 
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift

Re: Policy module to allow a domain transition

[Alan Stern]

On Tue, 17 Mar 2020, Dominick Grift wrote:

> > All right, so rather than try to change the programs, I added the
> > following TE rule:
> >
> > allow sshd_t unconfined_service_t:tcp_socket { getattr setopt };
> >
> > With that, sshd under tcpserver worked okay in permissive mode, with no
> > AVC notices in audit.log.  But when I changed to enforcing mode, the
> > program failed for no apparent reason (and again, no AVC messages).  
> > The remote system merely reported "Connection reset by peer".  Any idea
> > what's wrong?
> 
> You can run `semodule -DB` to make SELinux more verbose. (use `semodule
> -B` to make SELinux less verbose when youre done)
> 
> My guess is that some socket accesses are silently blocked. Is a long
> story but the socket read and write accessed might be silently blocked
> because they are often false positives caused by leaked file
> descriptors.
> 
> In this case the read write on tcp_socket would be legit and would need
> to be allowed.
> 
> So if you do a `semodule -DB` then reproduce a login, then look for avc
> denials related to sshd_t, unconfined_service_t and tcp_sockets (my bet
> is on read and write) but eventually sshd obviously also needs to
> "accept" connections as well. In other words: "tcp_socket { getattr
> setopt }" is incomplete but the next access attempts (read/write) are
> silently blocked by policy and so without that it cannot do its job.

You hit the nail on the head.  As it turns out, not only did sshd_t
need read/write access to the tcp_socket, so did sshd_net_t.  I have no
idea what that type is for, but when I added the permission the program 
worked.

Thanks for your help.

Alan Stern