All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominick Grift <dac.override@gmail.com>
To: peter enderborg <peter.enderborg@sony.com>
Cc: Alan Stern <stern@rowland.harvard.edu>, <selinux@vger.kernel.org>
Subject: Re: Policy module to allow a domain transition
Date: Mon, 16 Mar 2020 21:44:21 +0100	[thread overview]
Message-ID: <87tv2oghcq.fsf@gmail.com> (raw)
In-Reply-To: <c9b092e8-caa5-52dd-1efb-1a5ab324a68f@sony.com> (peter enderborg's message of "Mon, 16 Mar 2020 21:20:18 +0100")

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

      reply	other threads:[~2020-03-16 20:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-16 16:04 Policy module to allow a domain transition Alan Stern
2020-03-16 19:24 ` Dominick Grift
2020-03-17 14:03   ` Alan Stern
2020-03-17 15:51     ` Dominick Grift
2020-03-17 19:30       ` Alan Stern
2020-03-17 19:39         ` Dominick Grift
2020-03-18  0:55           ` Alan Stern
2020-03-16 20:20 ` peter enderborg
2020-03-16 20:44   ` Dominick Grift [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tv2oghcq.fsf@gmail.com \
    --to=dac.override@gmail.com \
    --cc=peter.enderborg@sony.com \
    --cc=selinux@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.