From: Dominick Grift <dominick.grift@defensec.nl>
To: Russell Coker <russell@coker.com.au>
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: machinectl shell policy
Date: Fri, 25 Dec 2020 12:37:17 +0100 [thread overview]
Message-ID: <ypjl4kka5d76.fsf@defensec.nl> (raw)
In-Reply-To: <5735537.jZnottUgFY@liv> (Russell Coker's message of "Fri, 25 Dec 2020 20:16:07 +1100")
Russell Coker <russell@coker.com.au> writes:
> On Friday, 25 December 2020 6:58:41 PM AEDT Dominick Grift wrote:
>> Russell Coker <russell@coker.com.au> writes:
>> > On Thursday, 24 December 2020 7:37:50 PM AEDT Dominick Grift wrote:
>> >> > To enable "machinectl shell" on recent versions of systemd we need
>> >> > something like the above policy (which is not complete or ideal, still
>> >> > doesn't work so no point polishing it) and something for the below.
>> >> > What
>> >> > is the below about?
>> >>
>> >> this should be thoroughly addressed. machined creates a login pty that
>> >> gets relabeled on login as per type_change rules.
>> >
>> > Currently it's not being relabeled on Debian, but that's a separate issue.
>>
>> Maybe the required type_change rules arent present?
>
> Here is all the policy to make it work. Maybe we should have a type like
> system_dbusd_devpts_t for this. This is not policy for inclusion, this is
> policy to discuss before writing that policy.
I created a machined_pty_t, and then allowed both systemd (unconfined &
user_systemd_t) as well as the various user types to type change from
machined_pty_t to user_pty_t
[root@brutus ~]# sesearch --type_change | grep machine
type_change sys.isid machine.daemon.loginpty:chr_file sys.pty; #
unconfined_t and systemd --system are "system" is sys.isid, sys.pty is system/unconfined pty)
type_change user.subj machine.daemon.loginpty:chr_file user.pty; # all
my confined login user shell domains are "user.subj"
type_change user.systemd.subj machine.daemon.loginpty:chr_file user.pty;
# this is systemd --user on behalf of confined login users
my systemd-machined policy:
https://git.defensec.nl/?p=dssp3.git;a=blob_plain;f=policy/systemd/systemd_machine.cil;hb=HEAD
>
> term_user_pty(user_systemd_t, user_devpts_t)
> term_login_pty(devpts_t)
> allow user_systemd_t user_devpts_t:chr_file rw_file_perms;
>
> # for machinectl shell
> allow sysadm_t systemd_machined_t:dbus send_msg;
> systemd_manage_userdb_runtime_dirs(systemd_machined_t)
> systemd_manage_userdb_runtime_sock_files(systemd_machined_t)
> term_use_ptmx(systemd_machined_t)
> dev_getattr_fs(systemd_machined_t)
> term_getattr_pty_fs(systemd_machined_t)
> allow systemd_machined_t sysadm_t:dbus send_msg;
> allow systemd_machined_t devpts_t:chr_file rw_file_perms;
> allow system_dbusd_t systemd_machined_t:fd use;
> allow system_dbusd_t devpts_t:chr_file { read write };
> allow system_dbusd_t ptmx_t:chr_file { read write };
> allow sysadm_t systemd_machined_t:fd use;
> allow user_systemd_t shell_exec_t:file entrypoint;
> allow user_systemd_t systemd_machined_t:fd use;
> allow user_systemd_t self:process signal;
> allow user_t systemd_machined_t:fd use;
> allow user_t user_systemd_t:fifo_file { getattr write };
> allow user_t init_t:process signal;
>
>> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892001
>> >
>> > We have work in progress on dbus-broker in Debian. Would it make sense to
>> > only support dbus-broker in SE Linux policy? Being forced to use only 1
>> > of
>> > the 2 dbus programs (and the newer and faster 1 of the 2) is a very small
>> > trade-off, smaller than some of the other trade-offs for running SE Linux.
>>
>> should probably be able to support both (conditionally) but could get messy
>
> Currently we have a heap of ifdef systemd in the policy, as probably the only
> people not wanting dbus-broker will be the ones not wanting systemd we could
> include it in the same ifdef rules.
--
gpg --locate-keys dominick.grift@defensec.nl
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-12-25 11:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-23 22:18 machinectl shell policy Russell Coker
2020-12-24 8:37 ` Dominick Grift
2020-12-25 5:12 ` Russell Coker
2020-12-25 7:58 ` Dominick Grift
2020-12-25 9:16 ` Russell Coker
2020-12-25 11:37 ` Dominick Grift [this message]
2021-01-04 14:48 ` Chris PeBenito
2021-01-04 15:00 ` Dominick Grift
2021-01-04 15:06 ` Dominick Grift
2021-01-04 15:13 ` 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=ypjl4kka5d76.fsf@defensec.nl \
--to=dominick.grift@defensec.nl \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).