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
References: <20190111103043.GA22910@xev>
        <4df64def-6cfe-af47-5c2a-dcdbf0d507e4@ieee.org>
        <2480376.JRpnWL4ehX@liv>
Date:   Tue, 15 Jan 2019 09:36:53 +0100
In-Reply-To: <2480376.JRpnWL4ehX@liv> (Russell Coker's message of "Tue, 15 Jan
        2019 18:47:13 +1100")
Message-ID: <8736pu9v16.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

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