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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.