machinectl shell policy

machinectl shell policy

[Russell Coker]

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/

Re: machinectl shell policy

[Dominick Grift]

Russell Coker <russell@coker.com.au> 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 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

Re: machinectl shell policy

[Russell Coker]

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/

Re: machinectl shell policy

[Dominick Grift]

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?

>
>> > 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 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

Re: machinectl shell policy

[Russell Coker]

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.

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/

Re: machinectl shell policy

[Dominick Grift]

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

Re: machinectl shell policy

[Chris PeBenito]

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@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.
> 
> 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

Re: machinectl shell policy

[Dominick Grift]

Chris PeBenito <pebenito@ieee.org> 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@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.
>> 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@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

Re: machinectl shell policy

[Dominick Grift]

Dominick Grift <dominick.grift@defensec.nl> writes:

> Chris PeBenito <pebenito@ieee.org> 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@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.
>>> 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 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

Re: machinectl shell policy

[Dominick Grift]

Dominick Grift <dominick.grift@defensec.nl> writes:

> Dominick Grift <dominick.grift@defensec.nl> writes:
>
>> Chris PeBenito <pebenito@ieee.org> 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@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.
>>>> 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 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