Livecd-creator is disabling selinux

Mon Jan 13 15:20:22 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/10/2014 10:47 PM, Dennis Gilmore wrote:
> El Fri, 10 Jan 2014 18:31:13 -0700 Tim Flink <tflink at redhat.com> escribió:
>> On Fri, 10 Jan 2014 15:35:59 -0800 Adam Williamson <awilliam at redhat.com>
>> wrote:
> 
>>> On Fri, 2014-01-10 at 17:33 -0600, Dennis Gilmore wrote:
>>>> El Fri, 10 Jan 2014 15:26:38 -0800 Adam Williamson
>>>> <awilliam at redhat.com> escribió:
>>>>> On Thu, 2014-01-09 at 11:32 +0100, Maros Zatko wrote:
>>>>>> Dear guys and ladies, So it seems like livecd-creator is silently
>>>>>> disabling selinux. Proof: vim $(which livecd-creator) ; line 150 
>>>>>> Fact, that it's re-enabled afterwards doesn't ease silent 
>>>>>> disablement of security feature.
>>>>>> 
>>>>>> I'd love to know the reason and if it's possible to do something
>>>>>> about it.
>>>>> 
>>>>> Because live images don't work properly if it's either disabled or
>>>>> enforcing while the image is being generated. Why *that* is I don't
>>>>> know, but before bcl made the livecd-creator script do this, we
>>>>> just had a bit in the livecd-creator instructions which said "you
>>>>> have to run setenforce Permissive before starting to build a live
>>>>> image".
>>>>> 
>>>>> If you try building a live image with SELinux either disabled or 
>>>>> enforcing on the build host, you wind up either with a compose that
>>>>> fails, or an image that can't be booted in enforcing mode.
>>>> 
>>>> Adam this is not true, All Offical Fedora images for years were built
>>>> on hosts with selinux disabled. F20 was the first time images were
>>>> built with the host in permissive mode, but then they are built in a
>>>> mock chroot which has selinux disabled in the chroot
>>> 
>>> Hum, I'm sure back before the script tried to take care of it for you,
>>> I'd had multiple failures with both 'enforcing' and 'disabled'. But if
>>> you say so...
> 
>> I've also run into problems with livecd-creator and was told the same 
>> thing: for best results, run with SELinux in permissive mode - not 
>> disabled and not enforcing.
> 
>> It was a while ago but I don't think that it was something I hit for 
>> every build. This leads me to suspect that whatever the issue is, it 
>> doesn't happen every time and the releng setup must be able to avoid 
>> whatever it is that people can (and do) hit with SELinux disabled or 
>> enforcing.
> 
>> Also, I think that until F20 releng was building livecds in mock chroots
>> on el boxes (dennis, please correct me if I'm wrong) where both you and I
>> were building livecds on fedora installs.
> 
> Tim,
> 
> F20 images were built in f20 chroots on f19 boxes. but selinux on the host
> was permissive. prior to f20 it was the target os chroot on el
> 
> Dennis
> 

The point being any of these tools to work with SELinux in enforcing mode, we
need the processes within the build tools to believe SELinux is disabled,
since we do not want them trying to do "SELinux" things, like loading policy.

Secondly we prevent even unconfined_t from putting down labels on the file
system that the kernel does not understand.  IE If I am building a F21 image
on a RHEL6 box, it would blow up in enforcing mode if run as unconfined_t.  We
added a special policy called livecd_t that is allowed to put down labels
which the kernel does not understand, and unconfined_t will transition to this
domain.