SELinux Security Module development
 help / color / mirror / Atom feed
From: Dominick Grift <dac.override@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: selinux@vger.kernel.org
Subject: Re: Policy module to allow a domain transition
Date: Mon, 16 Mar 2020 20:24:54 +0100	[thread overview]
Message-ID: <87y2s0gl15.fsf@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.2003161146070.8175-100000@netrider.rowland.org> (Alan Stern's message of "Mon, 16 Mar 2020 12:04:48 -0400 (EDT)")

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

  reply	other threads:[~2020-03-16 19:24 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 [this message]
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

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=87y2s0gl15.fsf@gmail.com \
    --to=dac.override@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox