[DSE-Dev] init: delegate selinux operation to separate binary

[Laurent Bigonville]

Le 18/05/19 à 13:31, Dmitry Bogatov a écrit :
> [2019-05-16 11:43] Laurent Bigonville<bigon at debian.org>
>> On Thu, 16 May 2019 08:54:43 +0000 Dmitry Bogatov<KAction at debian.org>  
>> wrote:
>>   >
>>   > From 7f6242e5f3d893e90b3ed44fb09abe5983c2d49a Mon Sep 17 00:00:00 2001
>>   > From: Dmitry Bogatov<KAction at debian.org>
>>   > Date: Wed, 15 May 2019 12:10:13 +0000
>>   > Subject: [PATCH] init: delegate selinux operation to separate binary
>> Can you please explain the rational behind this?
> 	This way, /sbin/init is no longer linked aganist libselinux (and its
> 	transitive dependencies).
>
> 	If user need selinux initialization, she can install
> 	/sbin/selinux-check separately.

I've seen that in your commit, I just don't understand why this is even 
a goal. libselinux is really small and only pulls libpcre3 which is 
pulled by grep (which is Essential). It's not possible today to install 
debian without libselinux installed anyway.

Also, what's your plan regarding packaging? Would that executable be put 
in a separate package? TBRH I spent a lot of time working opening 
bugs/submitting patches in debian so the user who wants to use SELinux 
can get (an almost) out of the box experience in debian and I would not 
really be happy to see that attempt to revert that in a core component.

If you really (really) want to go that way, maybe you should use a 
private path for the helper (as it shouldn't be called my regular users 
after the initial load) and/or use a less common name than "selinux-check".

>> This looks like a bad idea to me. SELinux needs to be initialized as
>> soon as possible during the boot otherwise this will call for issues.
> As you may see, this patch does not change time during boot, when
> selinux functions are called -- only moves them into child process.

But you are forking/exec() that usually requires SELinux permission, 
however as there would be no policy loaded yet at that moment that 
should be allowed by SELinux.

I don't know whether or not that would require a change in existing 
policies.


>> Was that discussed with anybody involved in SELinux in debian and/or
>> upstream?
> That is exactly place to start discussion. Luckily, Jesse is following
> BTS, and I do not have to go through Savannah issue tracker.

I was more thinking about upstream SELinux people

> PS. I removed -lselinux from INITLIBS in src/Makefile.
You mean -lsepol?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/selinux-devel/attachments/20190518/71cc8a32/attachment.html>