Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Chris PeBenito <pebenito@ieee.org>,
        Russell Coker <russell@coker.com.au>
Cc:     selinux-refpolicy@vger.kernel.org,
        Matej Marusak <mmarusak@redhat.com>
References: <YH6gq6yWUmo93KT7@xev> <ypjlbla9f4mk.fsf@defensec.nl>
 <574c5faf-0c19-8b9a-3bfe-a71d82a1f2e6@ieee.org>
From:   Dominick Grift <dominick.grift@defensec.nl>
Subject: Re: [PATCH] cockpit web admin system
Message-ID: <3f123c6d-d01a-a032-956e-c88dbde91468@defensec.nl>
Date:   Mon, 26 Apr 2021 15:22:14 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <574c5faf-0c19-8b9a-3bfe-a71d82a1f2e6@ieee.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 4/26/21 2:47 PM, Chris PeBenito wrote:
> On 4/20/21 9:49 AM, Dominick Grift wrote:
>> Russell Coker <russell@coker.com.au> writes:
>>
>>> I took this from the rawhide policy and adapted it to work with
>>> refpolicy.
>>>
>>> Probably not ready for merging yet, let me know what should be changed.
>>
>> Its been a while since I played with cockpit
>>
>> Theres one thing that I want to mention though, instead of login the
>> confined users in with their login shell domain consider confining the
>> cockpit-bridge instead and make it log users in with bridge context
>> instead of the login shell context.
> 
> Do you have an example of permissions that would be concerning?

The wide direct dbus access might be concerning.

cockpit-bridge (at least when I used it) seems to chat directly with
various system services like firewalld,tuned,udisks but also various
systemd components including pid1 (although not sure if the latter are
direct or via systemctl.

There's a bunch of other access that I can't explain anymore and some of
it does not make sense. Theres network access (connects to vnc and binds
tcp sockets to ephemeral ports)

I also allowed it to mapread shadow unconditionally but that does not
make sense as shadow is mode 000 and even if the bridge would be run by
a root login it still seems to not have cap_dac_read_search access ...

https://git.defensec.nl/?p=dssp2.git;a=blob;f=policy/services/c/cockpit.cil;h=f09d5084ba0c9f1b671b26772b29eb383c40e60a;hb=HEAD#l95

Things may have changed since then as well. I just wanted to give a
heads-up, it may be nothing to worry about.

> 
> 
>> Because otherwise you'll end up extending the login shell domain with
>> permissions needed by the bridge. You can still allow the bridge to open
>> up a shell with a transition back to the login shell domain (but then
>> you will get into domain prefixes
>>
>> ie: staff_bridge_t -> shell_exec_t -> staff_t vs. user_bridge_t ->
>> shell_exec_t -> user_t etc.
> 
> 
> Otherwise I only see some style cleanup needed.  Also there is an
> optional block in the admin interface for systemd calls.  Systemd is
> required for cockpit, so it shouldn't be optional, right?
>