On 12/25/20 4:16 AM, Russell Coker wrote:
On Friday, 25 December 2020 6:58:41 PM AEDT Dominick Grift wrote:
Russell Coker <russell@xxxxxxxxxxxx> 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.
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;
The pty stuff seems to make sense, but I'm curious why there is a transition
into user_systemd_t for the shell.
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.
I'd prefer to keep both unless it becomes onerous.
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.
The "else" of the ifdef can work.
--
Chris PeBenito
