From: cpebenito@tresys.com (Christopher J. PeBenito)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] system_r transition in _admin interfaces
Date: Tue, 12 May 2015 13:04:29 -0400 [thread overview]
Message-ID: <5552329D.4000005@tresys.com> (raw)
In-Reply-To: <20150512161913.GA12436@meriadoc.Home>
On 5/12/2015 12:19 PM, Jason Zaman wrote:
> Hi all,
>
> In basically all of the foo_admin() interfaces there are the following
> exact same rules:
>
> init_labeled_script_domtrans($1, ntpd_initrc_exec_t)
> domain_system_change_exemption($1)
> role_transition $2 ntpd_initrc_exec_t system_r;
> allow $2 system_r;
>
> Do these even work anymore? They dont work on OpenRC and as far as I
> know SystemD doesnt work like that either. I dont really like having the
> system_r transition around if it doesnt even work as it should.
>
>>From what I understand they are used so that if another role wants to
> admin the service you just add ntp_admin(ntpadm_t, ntpadm_r) and it will
> then be allowed to start/stop ntp.
>
> If I pull those lines out of all the _admin interfaces and make a
> separate interface that calls those, would the patch be accepted? Then
> inside that interface it would be easy to ifdef systemd, or ifdef
> openrc or whatever kind of init is being used and needs special rules.
I think what we're getting at is actually a more abstract interface: the
perms to start/stop a daemon. The above rules are what it takes for
traditional sysvinit-like services, while systemd and openrc have their
own behaviors. So I think we should replace the above lines in the
admin interfaces with calls to interfaces that look like (pseudocode):
in init.if:
define init_start_service_template
ifdef init_systemd:
allow $caller $domain:service start;
else ifdef init_sysvinit or init_upstart:
init_labeled_script_domtrans($caller, $entrypoint)
domain_system_change_exemption($caller)
...
else ifdef init_openrc
...
endif
in ntp.if:
template ntp_start_service
init_start_service_template($caller, $role, ntpd_t, ntpd_initrc_exec_t)
Then with these in place, it should hopefully work right without much
effort, and the individual modules don't know or care about the details
of start/stop a service.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
next prev parent reply other threads:[~2015-05-12 17:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 16:19 [refpolicy] system_r transition in _admin interfaces Jason Zaman
2015-05-12 16:31 ` Dominick Grift
2015-05-12 16:46 ` Jason Zaman
2015-05-12 17:04 ` Christopher J. PeBenito [this message]
2015-05-12 18:04 ` Jason Zaman
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=5552329D.4000005@tresys.com \
--to=cpebenito@tresys.com \
--cc=refpolicy@oss.tresys.com \
/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.