From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] systemd policy
Date: Mon, 13 Jan 2014 10:10:11 -0500 [thread overview]
Message-ID: <52D401D3.5040900@redhat.com> (raw)
In-Reply-To: <5347508.kSSh66cgIv@russell.coker.com.au>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/13/2014 07:52 AM, Russell Coker wrote:
> On Sun, 12 Jan 2014 13:18:41 Laurent Bigonville wrote:
>> Daniel do you know when this will happen? Can I already propose some of
>> these patches?
>
> One thing that would be good to propose first is the labelling of unit
> files.
>
> Currently in Debian policy we have lots of patches to daemon policy like
> the following. If we can agree that each daemon should have it's own unit
> file type (which appears to me to have no benefit unless we make a
> significant addition to the daemon management functionality) then we can
> add the patch as- is. If we are going to add it as-is then the sooner the
> better, as a patch that affects lots of files is annoying to maintain.
>
> type apcupsd_unit_file_t; systemd_unit_file(apcupsd_unit_file_t)
>
> /lib/systemd/system/apcupsd\.service --
> gen_context(system_u:object_r:apcupsd_unit_file_t,s0)
>
> It seems to me that the only benefit of per-daemon types is that we can
> write policy allowing one user access to manage daemons with several
> types.
>
> The other possible way of allowing per-user management of daemons managed
> by the type of the unit file would be to have a default type for the unit
> files (which is easier for .fc files and no change to most daemon policy).
> Then whenever we need to delegate some sysadmin rights to a daemon we
> create a new type as appropriate and a fcontext rule to label the unit
> file.
>
> Regardless of when we merge the patches it would be good to get this design
> issue sorted out soon.
>
Having separate labels on the unit file is not just for "user" domains. It
is also for system domains, for example NetworkManager_t is allowed to start
the following services.
sesearch -A -s NetworkManager_t -p start
Found 5 semantic av rules:
allow NetworkManager_t nscd_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t ntpd_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t pppd_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t polipo_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t dnsmasq_unit_file_t : service { start stop status
reload } ;
I rely on Dominick and Miroslav to get Fedora changes/fixes upstream.
Could you guys take care of getting systemd policy upstream.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLUAdMACgkQrlYvE4MpobN05gCeOxOi9JtmMoiCfovdC5np0ed8
1BkAnRzCRpGoIiHTY0E1D7OjHIFPHnp1
=wZz7
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-01-13 15:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-12 7:06 [refpolicy] systemd policy Russell Coker
2014-01-12 12:18 ` Laurent Bigonville
2014-01-13 12:52 ` Russell Coker
2014-01-13 15:10 ` Daniel J Walsh [this message]
2014-01-13 19:02 ` Dominick Grift
2014-01-13 20:16 ` Daniel J Walsh
2014-01-13 20:22 ` Dominick Grift
2014-01-13 21:07 ` Dominick Grift
2014-01-14 14:49 ` Daniel J Walsh
2014-01-14 11:24 ` Dominick Grift
2014-01-13 23:37 ` Russell Coker
2014-01-14 9:46 ` Dominick Grift
2014-01-14 9:58 ` Dominick Grift
2014-01-14 12:35 ` Laurent Bigonville
2014-01-14 13:03 ` Dominick Grift
2014-01-27 6:56 ` Russell Coker
2014-02-06 14:40 ` Christopher J. PeBenito
2014-01-14 10:12 ` Dominick Grift
2014-01-14 12:22 ` Laurent Bigonville
2014-01-14 13:34 ` Christopher J. PeBenito
2014-01-14 13:54 ` Dominick Grift
2014-01-14 14:41 ` Laurent Bigonville
2014-01-14 14:55 ` Daniel J Walsh
2014-01-27 14:17 ` Miroslav Grepl
2014-02-06 16:32 ` Christopher J. PeBenito
-- strict thread matches above, loose matches on Subject: below --
2015-10-19 18:17 [refpolicy] Systemd policy Christopher J. PeBenito
2015-10-20 11:35 ` Dominick Grift
2015-10-23 19:23 ` Christopher J. PeBenito
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=52D401D3.5040900@redhat.com \
--to=dwalsh@redhat.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.