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;
From:   Dominick Grift <dominick.grift@defensec.nl>
To:     Denis Obrezkov <denisobrezkov@gmail.com>
Cc:     Russell Coker <russell@coker.com.au>,
        selinux-refpolicy@vger.kernel.org
Subject: Re: Are we on the wrong track?
References: <3243717.6S2XvbbdUs@liv>
        <f4abbf59-5a51-31c5-ae39-6a43914b890b@gmail.com>
Date:   Fri, 12 Jun 2020 13:57:53 +0200
In-Reply-To: <f4abbf59-5a51-31c5-ae39-6a43914b890b@gmail.com> (Denis
        Obrezkov's message of "Fri, 12 Jun 2020 13:00:05 +0200")
Message-ID: <ypjla718pkce.fsf@defensec.nl>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

Denis Obrezkov <denisobrezkov@gmail.com> writes:

> Hi, Russell,

Not Russell but allow me...

>
> I am a novice in SELinux, even though I am learning it for a year or so.
> And I can't really understand why SELinux is SO complex. Not only the
> policy, but the whole SELinux.

In time i've learned to appreciate the simplicity and elegance of
SELinux given the tasks it accomplishes. I acknowledge that it may take
some time for one to see that "light".

> For example, there are two different ways of writing a policy - CIL and

There are actually 4 different way's of writing a policy. It's
evolution.

1. Monolitic policy
2. Modular policy
3. Reference policy
4. Common Intermediate Language

> the other one. And they have conflicting namesets (typeattribute =
> atttribute). At the same time, this behavior is just slightly
> documented. One can't create a policy only using information from docs.

I suspect that when the "attribute" statement was created no one had
foreseen that we eventually would end up with not just a "type
attribute" but also with a "user" and "role' "attribute". CIL merely
corrected this by renaming it all in a more consistent way where the
existing languages were unable to rename it for compatibility reasons:

CIL:

1. typeattribute
2. roleattribute
3. userattribute

Old:

1. attribute
2. attribute_role
3. (not even sure is user attributes are supported in anything but CIL)

> At the same time, some parts of SELinux are very unstable. Like, MCS. It

Creating a policy (from scratch) is indeed not very well documented
AFAIK. There is however a script in the kernel documentation tree called
MDP that creates a simple policy. This script can be used to get at
least some idea of what it takes to write a policy.

> was introduced and it is used only for VM management. And mcstransd is

Not everyone will agree with me probably but to me MCS was alway's a
"hack" to make some use of MLS in systems that do not enforce
confidentiality. The term hack here is meant in a good way: to highlight
how flexible SELinux is.
MCS also evolved over time, and eventually I think the current
implementation of this "hack" is the most useful. It may (or may not)
by known as "SVIRT" but really its just a technique to use the
compartments of MLS to accomplish seperation and the use case for this
is actually broader than you may think. The usuability of MCS might also
be easier than you think. I played with MCS just the other day to
separate python web application containers with gunicorn/django and
systemd/systemd-portable and it just works for me.

No need for mcstransd. mcstransd is really only used in some MLS
environments where the levels need to be human readable. This is not a
requirement for common MCS seperation. mcstransd just adds overhead.

> bad. It's really bad. I was trying to use it and it was totally
> unstable. So, even if someone wants to use MCS - it is almost impossible
> because tools are unstable and MCS is already almost exclusively used by
> VMs.
>
> On 12.06.20 02:03, Russell Coker wrote:
>> The reference policy is getting an increasing number of domains and types with 
>> an O(N^2) level of complexity for writing policy and an O(N^2) size of the 
>> binary policy.  In 2012 the binary policy on my machines was 560k, now it's 
>> over 2M.
>> 
>> In recent policy we have 6 different domains for systemd-generators.  What 
>> benefit are we expecting to get from this?  Are we anticipating that one 
>> generator will attack another?  How would having separate domains for 
>> generators do any good when there's no restriction on the contents of the 
>> files they generate and nothing to prevent one generator from creating a file 
>> of the name that another generator is expected to create?  Is it even 
>> reasonable to expect that a program that can create a systemd unit file with 
>> arbitrary content (IE being able to start any daemon with arbitrary 
>> configuration and command-line parameters) would be unable to exploit that for 
>> unrestricted root access?
>> 
>> We have a new set of domains, user_wm_t, staff_wm_t, etc.  What is that for?  
>> Is someone using the X controls and in need of a privileged window manager 
>> domain to manage the clipboard etc?  Why is staff_wm_t needed when we no 
>> longer have staff_gpg_t?  Does staff_r even make sense when you could just use 
>> different MCS categories for different users?
>> 
>> We have one games_t domain for games which were packaged by the distribution.  
>> Is this possible to give a useful benefit given that they some games the same 
>> XDG config directories as more important things.  If a game has the file 
>> access needed to grab passwords from your MUA and network access to send them 
>> out then is there a real benefit in having a separate domain for it?  As an 
>> aside I think that the ideal thing to do would be to have a SETGID program to 
>> manage passwords for email etc that prevents the user from accessing them, it 
>> could then proxy IMAP/SMTP connections so the MUA never knows the real 
>> passwords.
>> 
>> We have special *_cronjob_t domains which in systems that use them (IE not 
>> Debian) seem to give the potential for nothing but confusion.  The general 
>> expectation is that anything which can run as a user login session can also 
>> run as a cron job.  What benefit is this expected to provide?
>> 

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift