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; 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. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/