From: Dominick Grift <dac.override@gmail.com>
To: "Sugar\, David" <dsugar@tresys.com>
Cc: "selinux-refpolicy\@vger.kernel.org"
<selinux-refpolicy@vger.kernel.org>
Subject: Re: [PATCH 1/2 v2] Allow greeter to start dbus
Date: Sun, 06 Jan 2019 13:54:55 +0100 [thread overview]
Message-ID: <874lam7xpc.fsf@gmail.com> (raw)
In-Reply-To: <bb6ad7ff-4904-fd32-3b3f-760e75e3ca6f@tresys.com> (David Sugar's message of "Sun, 6 Jan 2019 12:50:47 +0000")
"Sugar, David" <dsugar@tresys.com> writes:
> On 1/6/19 7:40 AM, Dominick Grift wrote:
>> "Sugar, David" <dsugar@tresys.com> writes:
>>
>>> The display manager lightdm (and I think gdm) start a dbus binary.
>>>
>>> This adds (and uses) new interface dbus_exec to start dbus in the xdm domain.
>>>
>>> type=AVC msg=audit(1544626796.378:201): avc: denied { execute } for pid=9973 comm="dbus-launch" name="dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
>>> type=AVC msg=audit(1544626796.378:201): avc: denied { read open } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
>>> type=AVC msg=audit(1544626796.378:201): avc: denied { execute_no_trans } for pid=9973 comm="dbus-launch" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
>>> type=AVC msg=audit(1544626796.378:201): avc: denied { map } for pid=9973 comm="dbus-daemon" path="/usr/bin/dbus-daemon" dev="dm-1" ino=6695040 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_exec_t:s0 tclass=file permissive=1
>>> type=AVC msg=audit(1546551459.112:208): avc: denied { getcap } for pid=6275 comm="dbus-daemon" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process permissive=1
>>>
>>> Signed-off-by: Dave Sugar <dsugar@tresys.com>
>>> ---
>>> policy/modules/services/dbus.if | 21 +++++++++++++++++++++
>>> policy/modules/services/xserver.te | 1 +
>>> 2 files changed, 22 insertions(+)
>>>
>>> diff --git a/policy/modules/services/dbus.if b/policy/modules/services/dbus.if
>>> index ef829e30..d0eec745 100644
>>> --- a/policy/modules/services/dbus.if
>>> +++ b/policy/modules/services/dbus.if
>>> @@ -17,6 +17,27 @@ interface(`dbus_stub',`
>>> ')
>>> ')
>>>
>>> +########################################
>>> +## <summary>
>>> +## Execute dbus in the caller domain.
>>> +## </summary>
>>> +## <param name="domain">
>>> +## <summary>
>>> +## Domain allowed access.
>>> +## </summary>
>>> +## </param>
>>> +#
>>> +interface(`dbus_exec',`
>>> + gen_require(`
>>> + type dbusd_exec_t;
>>> + ')
>>> +
>>> + corecmd_search_bin($1)
>>> + can_exec($1, dbusd_exec_t)
>>> +
>>> + allow $1 self:process getcap;
>> I would not enclose the getcap rule here. For example I do not believe
>> you need that permission to be able to `dbus-daemon --version`. Instead I
>> would add that rule to xserver.te:
>>
>> allow xdm_t self:process getcap;
>
> I did it this way due to the fact that it is dbus-daemon needing the
> getcap permission not lightdm. So other processes that use the
> dbus_exec interface will also need this permission. I'm happy separate
> just worry it won't be clear why getcap will be added in several places
> due to this.
>
`dbus-daemon --version` does not seem to require getcap
executing dbus potentially requires many permissions but that does not
mean that we should add these permissions to dbus_exec()
>>> +')
>>> +
>>> ########################################
>>> ## <summary>
>>> ## Role access for dbus.
>>> diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
>>> index fa7ce88e..cc717e7f 100644
>>> --- a/policy/modules/services/xserver.te
>>> +++ b/policy/modules/services/xserver.te
>>> @@ -566,6 +566,7 @@ optional_policy(`
>>> ')
>>>
>>> optional_policy(`
>>> + dbus_exec(xdm_t)
>>> dbus_system_bus_client(xdm_t)
>>> dbus_connect_system_bus(xdm_t)
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
prev parent reply other threads:[~2019-01-06 12:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-06 12:34 [PATCH 1/2 v2] Allow greeter to start dbus Sugar, David
2019-01-06 12:34 ` [PATCH 2/2 v2] pam_faillock creates files in /run/faillock Sugar, David
2019-01-06 12:47 ` Dominick Grift
2019-01-06 12:40 ` [PATCH 1/2 v2] Allow greeter to start dbus Dominick Grift
2019-01-06 12:50 ` Sugar, David
2019-01-06 12:54 ` Dominick Grift [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874lam7xpc.fsf@gmail.com \
--to=dac.override@gmail.com \
--cc=dsugar@tresys.com \
--cc=selinux-refpolicy@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).