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)
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?
type=USER_AVC msg=audit(1608759091.934:1799): pid=324 uid=108 auid=4294967295
ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:
denied { 0x2 } for msgtype=error
error_name=org.freedesktop.DBus.Error.FileNotFound dest=:1.18 spid=2642
tpid=2706 scontext=system_u:system_r:systemd_machined_t:s0
tcontext=bofh:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=(null) permissive=0
exe="/usr/bin/dbus-daemon" sauid=108 hostname=? addr=?
terminal=?'UID="messagebus" AUID="unset" SAUID="messagebus"
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Russell Coker <[email protected]> writes:
> 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)
>
> 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.
>
> type=USER_AVC msg=audit(1608759091.934:1799): pid=324 uid=108 auid=4294967295
> ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:
> denied { 0x2 } for msgtype=error
> error_name=org.freedesktop.DBus.Error.FileNotFound dest=:1.18 spid=2642
> tpid=2706 scontext=system_u:system_r:systemd_machined_t:s0
> tcontext=bofh:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=(null) permissive=0
> exe="/usr/bin/dbus-daemon" sauid=108 hostname=? addr=?
> terminal=?'UID="messagebus" AUID="unset" SAUID="messagebus"
Yes i noticed the above as well on debian with dbus-daemon, i dont see
any of these on fedora with dbus-broker
By the way we probably shouldnt use the same dbus policy for both
dbus-daemon and dbus-broker because theyre pretty different.
* dbus-broker does not check method returns (dbus-daemon does)
* dbus-broker is systemd specific (dbus activation works via systemd)
--
gpg --locate-keys [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
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.
> > type=USER_AVC msg=audit(1608759091.934:1799): pid=324 uid=108
> > auid=4294967295 ses=4294967295
> > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied {
> > 0x2 } for msgtype=error
> > error_name=org.freedesktop.DBus.Error.FileNotFound dest=:1.18 spid=2642
> > tpid=2706 scontext=system_u:system_r:systemd_machined_t:s0
> > tcontext=bofh:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=(null) permissive=0
> > exe="/usr/bin/dbus-daemon" sauid=108 hostname=? addr=?
> > terminal=?'UID="messagebus" AUID="unset" SAUID="messagebus"
>
> Yes i noticed the above as well on debian with dbus-daemon, i dont see
> any of these on fedora with dbus-broker
>
> By the way we probably shouldnt use the same dbus policy for both
> dbus-daemon and dbus-broker because theyre pretty different.
>
> * dbus-broker does not check method returns (dbus-daemon does)
> * dbus-broker is systemd specific (dbus activation works via systemd)
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.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Russell Coker <[email protected]> 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?
>
>> > type=USER_AVC msg=audit(1608759091.934:1799): pid=324 uid=108
>> > auid=4294967295 ses=4294967295
>> > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied {
>> > 0x2 } for msgtype=error
>> > error_name=org.freedesktop.DBus.Error.FileNotFound dest=:1.18 spid=2642
>> > tpid=2706 scontext=system_u:system_r:systemd_machined_t:s0
>> > tcontext=bofh:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=(null) permissive=0
>> > exe="/usr/bin/dbus-daemon" sauid=108 hostname=? addr=?
>> > terminal=?'UID="messagebus" AUID="unset" SAUID="messagebus"
>>
>> Yes i noticed the above as well on debian with dbus-daemon, i dont see
>> any of these on fedora with dbus-broker
>>
>> By the way we probably shouldnt use the same dbus policy for both
>> dbus-daemon and dbus-broker because theyre pretty different.
>>
>> * dbus-broker does not check method returns (dbus-daemon does)
>> * dbus-broker is systemd specific (dbus activation works via systemd)
>
> 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
--
gpg --locate-keys [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
On Friday, 25 December 2020 6:58:41 PM AEDT Dominick Grift wrote:
> Russell Coker <[email protected]> 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/
Russell Coker <[email protected]> writes:
> On Friday, 25 December 2020 6:58:41 PM AEDT Dominick Grift wrote:
>> Russell Coker <[email protected]> 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 [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
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 <[email protected]> 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
Chris PeBenito <[email protected]> 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 <[email protected]> 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 [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
Dominick Grift <[email protected]> writes:
> Chris PeBenito <[email protected]> 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 <[email protected]> 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
And I agree that then user_systemd_t shell_exec_t entrypoint should be
there.
>
>
>>
>>> 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 [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
Dominick Grift <[email protected]> writes:
> Dominick Grift <[email protected]> writes:
>
>> Chris PeBenito <[email protected]> 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 <[email protected]> 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
>
> And I agree that then user_systemd_t shell_exec_t entrypoint should be
> there.
err, *should not be there*
>
>>
>>
>>>
>>>> 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 [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift