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
next prev parent 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