Chris PeBenito <pebenito@xxxxxxxx> writes: > 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. The policy above is referencing "devpts_t", that is sub-optimal. there shouldnt be any pty chr files with the devpts_t filesystem type > >> 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. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift