From: Dominick Grift <dac.override@gmail.com>
To: Russell Coker <russell@coker.com.au>
Cc: Chris PeBenito <pebenito@ieee.org>, selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH] some little stuff
Date: Tue, 15 Jan 2019 09:36:53 +0100 [thread overview]
Message-ID: <8736pu9v16.fsf@gmail.com> (raw)
In-Reply-To: <2480376.JRpnWL4ehX@liv> (Russell Coker's message of "Tue, 15 Jan 2019 18:47:13 +1100")
Russell Coker <russell@coker.com.au> writes:
> On Sunday, 13 January 2019 6:28:35 AM AEDT Chris PeBenito wrote:
>> > Index: refpolicy-2.20180701/policy/modules/system/systemd.te
>> > ===================================================================
>> > --- refpolicy-2.20180701.orig/policy/modules/system/systemd.te
>> > +++ refpolicy-2.20180701/policy/modules/system/systemd.te
>> > @@ -337,6 +337,10 @@ optional_policy(`
>> > networkmanager_dbus_chat(systemd_hostnamed_t)
>> > ')
>> >
>> > +optional_policy(`
>> > + unconfined_dbus_send(systemd_hostnamed_t)
>> > +')
>>
>> This comment:
>>
>> https://github.com/SELinuxProject/refpolicy/issues/18#issuecomment-452316615
>>
>> makes me rethink all dbus sends to unconfined domains, especially
>> unconfined_t. This here isn't all confined domains, but I want more
>> consideration for the perm.
>
> That comment is about allowing all domains to send to unconfined_t. Allowing
> specific domains like systemd_hostnamed_t to send to unconfined_t doesn't seem
> like a problem. It doesn't seem likely that an attack via dbus would start
> with a systemd domain, especially not one like systemd_hostnamed_t.
Not completely accurate. The comment is not about "all" domains, its
about "all" domains that already have access to dbus. However I kind of
agree here that it's probably not worth it to go down this rabbit hole.
Even the normal dbus_chat interfaces are too broad (and that is
inevitable), and potentially allow for atleast some form of priv escalation
more often then not.
It just a dbus design issue IMHO.
This is also why i added that commit in the first place. I knew that it
was a (big) compromise but i just chose to add it anyway (without any
discussion, which was wrong). I still allow this access in DSSP2, I just
made a note about it in the README. There are just weak spots in the
policy such as DBUS and unconfined. As long as you are aware of them you
can to some extent anticipate that.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
next prev parent reply other threads:[~2019-01-15 8:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 10:30 [PATCH] some little stuff Russell Coker
2019-01-12 19:28 ` Chris PeBenito
2019-01-15 7:47 ` Russell Coker
2019-01-15 8:36 ` Dominick Grift [this message]
2019-01-16 23:04 ` Chris PeBenito
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=8736pu9v16.fsf@gmail.com \
--to=dac.override@gmail.com \
--cc=pebenito@ieee.org \
--cc=russell@coker.com.au \
--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.