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:   Russell Coker <russell@coker.com.au>
To:     Denis Obrezkov <denisobrezkov@gmail.com>
Cc:     selinux-refpolicy@vger.kernel.org
Subject: Re: Are we on the wrong track?
Date:   Fri, 12 Jun 2020 21:53:35 +1000
Message-ID: <18730491.WiRWafRUmg@liv>
In-Reply-To: <f4abbf59-5a51-31c5-ae39-6a43914b890b@gmail.com>
References: <3243717.6S2XvbbdUs@liv> <f4abbf59-5a51-31c5-ae39-6a43914b890b@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

On Friday, 12 June 2020 9:00:05 PM AEST Denis Obrezkov wrote:
> At the same time, some parts of SELinux are very unstable. Like, MCS. It
> was introduced and it is used only for VM management. And mcstransd is
> 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.

Systemd has the ability to dynamically create and manage UIDs.  It could do 
the same with MCS categories.  Having systemd manage multiple daemons doing 
similar tasks with either MCS categories or the other systemd mechanisms 
(namespaces etc) used to isolate them instead of different types is something 
we could do.  There are a heap of daemons that use a TCP or UDP socket, write 
to logs, and maintain a data store (database server, proxy server, dhcp 
server, and samba all look fairly similar from a certain perspective), having 
an entirely separate policy for each one doesn't seem useful.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/