How to avoid relabeling rootfs at every boot

How to avoid relabeling rootfs at every boot

[Ian M]

Hello,

I hope this is the right list for this question:

I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but since the rootfs is a ramdisk the changes do not survive a system reboot.

I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.


Thanks,

Ian

Re: How to avoid relabeling rootfs at every boot

[James Carter]

On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@gmail.com> wrote:
>
> Hello,
>
> I hope this is the right list for this question:
>
> I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but since the rootfs is a ramdisk the changes do not survive a system reboot.
>
> I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.
>
Filesystem labels are not applied when the policy is labeled. On
filesystems that support xattrs, a fs_use_xattr rule is used to tell
SELinux to use the label stored in the security.selinux xattrs, but
the filesystem will still have to be labeled initially. If the fs does
not support xattrs and every file can be labeled the same, then a
genfscon rule can be used.

I am not sure of your exact case, but you can find more information in
the SELinux Notebook - See
https://github.com/SELinuxProject/selinux-notebook

Jim

>
> Thanks,
>
> Ian

Re: How to avoid relabeling rootfs at every boot

[William Roberts]

On Fri, Oct 23, 2020 at 2:05 PM James Carter <jwcart2@gmail.com> wrote:
>
> On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@gmail.com> wrote:
> >
> > Hello,
> >
> > I hope this is the right list for this question:
> >
> > I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but

IIRC, when I worked on the Android integration we had to do the same
thing. Android comes with it's own init in the ramdisk, so we just
called restorecon on the parts of
ramdisk that were of interest within the init daemon codebase itself.
I don't think theirs anyway around that IIRC as the CPIO archive
doesn't support xattrs.

I do recall seeing this patchset:
https://lwn.net/Articles/788922/

I didn't look much into it, but if that got merged, you might be able
to apply labels to ramdisk images.

> since the rootfs is a ramdisk the changes do not survive a system reboot.
> >
> > I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.
> >
> Filesystem labels are not applied when the policy is labeled. On
> filesystems that support xattrs, a fs_use_xattr rule is used to tell
> SELinux to use the label stored in the security.selinux xattrs, but
> the filesystem will still have to be labeled initially. If the fs does
> not support xattrs and every file can be labeled the same, then a
> genfscon rule can be used.
>
> I am not sure of your exact case, but you can find more information in
> the SELinux Notebook - See
> https://github.com/SELinuxProject/selinux-notebook
>
> Jim
>
> >
> > Thanks,
> >
> > Ian

Re: How to avoid relabeling rootfs at every boot

[James Carter]

(Adding the SELinux back on as a cc)

A file_contexts file is created when the policy is built using
Refpolicy or CIL. It must be created manually when using checkpolicy
on a policy.conf file. Since you are using restorecon, I would guess
that there is a file_contexts file in
/etc/selinux/targeted/contexts/files/.
Jim



On Fri, Oct 23, 2020 at 4:14 PM Ian M <merinian@gmail.com> wrote:
>
> It answers half my question I think,
>
> The other half being where is the initial label coming from?    As Bill said the cpio does not support xattr so that field is empty on boot and is populated sometime after.
>
> If I knew when and why that labeling was happening I think I'd be in a good position to move forward with my work.
>
> Thanks,
>
> Ian
>
> On Fri, Oct 23, 2020 at 4:12 PM Ian M <merinian@gmail.com> wrote:
>>
>>
>>
>> On Fri, Oct 23, 2020 at 4:02 PM James Carter <jwcart2@gmail.com> wrote:
>>>
>>> Does Bill's response on the SELinux list answer your question?
>>>
>>> Jim
>>>
>>>
>>> On Fri, Oct 23, 2020 at 2:18 PM Ian M <merinian@gmail.com> wrote:
>>> >
>>> > Hi Jim,
>>> >
>>> > Thanks for your response.
>>> >
>>> > My confusion surrounds how the filesystem gets its initial labels, they do not seem to be coming from the policy itself.
>>> >
>>> > e.g. the contents of /bin/ should be labeled bin_t according to the policy, but are root_t at boot.
>>> >
>>> > The filesystem does support xattrs, but as it is a ramdisk used to boot linux the extended attributes do not survive a reboot.
>>> >
>>> > Thanks,
>>> >
>>> >
>>> > Ian
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Fri, Oct 23, 2020 at 2:06 PM James Carter <jwcart2@gmail.com> wrote:
>>> >>
>>> >> On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@gmail.com> wrote:
>>> >> >
>>> >> > Hello,
>>> >> >
>>> >> > I hope this is the right list for this question:
>>> >> >
>>> >> > I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but since the rootfs is a ramdisk the changes do not survive a system reboot.
>>> >> >
>>> >> > I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.
>>> >> >
>>> >> Filesystem labels are not applied when the policy is labeled. On
>>> >> filesystems that support xattrs, a fs_use_xattr rule is used to tell
>>> >> SELinux to use the label stored in the security.selinux xattrs, but
>>> >> the filesystem will still have to be labeled initially. If the fs does
>>> >> not support xattrs and every file can be labeled the same, then a
>>> >> genfscon rule can be used.
>>> >>
>>> >> I am not sure of your exact case, but you can find more information in
>>> >> the SELinux Notebook - See
>>> >> https://github.com/SELinuxProject/selinux-notebook
>>> >>
>>> >> Jim
>>> >>
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > Ian

Re: How to avoid relabeling rootfs at every boot

[Ian M]

Thanks, cpio supporting extended attributes would be very helpful right now.

After looking through the ref policy I see there is a genfscon statement for rootfs which is what is labeling everything as root_t.

Would I break everything terribly if I removed that and setup an fs_use_xattr for the rootfs?


Thanks,

Ian Merin

> On Oct 23, 2020, at 3:49 PM, William Roberts <bill.c.roberts@gmail.com> wrote:
> 
> On Fri, Oct 23, 2020 at 2:05 PM James Carter <jwcart2@gmail.com> wrote:
>> 
>>> On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> I hope this is the right list for this question:
>>> 
>>> I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but
> 
> IIRC, when I worked on the Android integration we had to do the same
> thing. Android comes with it's own init in the ramdisk, so we just
> called restorecon on the parts of
> ramdisk that were of interest within the init daemon codebase itself.
> I don't think theirs anyway around that IIRC as the CPIO archive
> doesn't support xattrs.
> 
> I do recall seeing this patchset:
> https://lwn.net/Articles/788922/
> 
> I didn't look much into it, but if that got merged, you might be able
> to apply labels to ramdisk images.
> 
>> since the rootfs is a ramdisk the changes do not survive a system reboot.
>>> 
>>> I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.
>>> 
>> Filesystem labels are not applied when the policy is labeled. On
>> filesystems that support xattrs, a fs_use_xattr rule is used to tell
>> SELinux to use the label stored in the security.selinux xattrs, but
>> the filesystem will still have to be labeled initially. If the fs does
>> not support xattrs and every file can be labeled the same, then a
>> genfscon rule can be used.
>> 
>> I am not sure of your exact case, but you can find more information in
>> the SELinux Notebook - See
>> https://github.com/SELinuxProject/selinux-notebook
>> 
>> Jim
>> 
>>> 
>>> Thanks,
>>> 
>>> Ian

Re: How to avoid relabeling rootfs at every boot

[William Roberts]

On Fri, Oct 23, 2020 at 5:20 PM Ian M <merinian@gmail.com> wrote:
>
> Thanks, cpio supporting extended attributes would be very helpful right now.
>
> After looking through the ref policy I see there is a genfscon statement for rootfs which is what is labeling everything as root_t.

Yeah, genfscon is the way to say, hey this filesystem, all things have
this label. genfscon takes paths, for more specific labelling,
IIRC, cannot be used on rootfs; that feature only works for proc/sysfs
like pseudo filesystems.

>
> Would I break everything terribly if I removed that and setup an fs_use_xattr for the rootfs?

Yes because there is no xattr support, so it would choke and die when
the kernel wants the xattr.

Here's some other things to consider:
1. There is no xattr support. You would need to see if that patch or
something equivalent was accepted and then what kernel
    version, and determine if your kernel supports it. Then at build
time for the image you would have to create that dotfile that contains
the
    labels and package it in the CPIO archive. Then you could use the
fs_use_xattr IIUC.
2. I could be mistaken, but I think in recent years I have seen
patches or articles that other FS types can be used for the initial
root filesystem
    now without a need for initrd, so you could, IIUC, boot directly
into a labelled ext4 filesystem. You would have to label that file
system during build.
3. Most linuxt things boot into an initrd and then pivot to the actual
root filesystem, you could do that as well.

This would take some digging likely to figure out, or find someone
that knows way more than me. That shouldn't be too terribly hard,
I don't know much.

>
>
> Thanks,
>
> Ian Merin
>
> > On Oct 23, 2020, at 3:49 PM, William Roberts <bill.c.roberts@gmail.com> wrote:
> >
> > On Fri, Oct 23, 2020 at 2:05 PM James Carter <jwcart2@gmail.com> wrote:
> >>
> >>> On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@gmail.com> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I hope this is the right list for this question:
> >>>
> >>> I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but
> >
> > IIRC, when I worked on the Android integration we had to do the same
> > thing. Android comes with it's own init in the ramdisk, so we just
> > called restorecon on the parts of
> > ramdisk that were of interest within the init daemon codebase itself.
> > I don't think theirs anyway around that IIRC as the CPIO archive
> > doesn't support xattrs.
> >
> > I do recall seeing this patchset:
> > https://lwn.net/Articles/788922/
> >
> > I didn't look much into it, but if that got merged, you might be able
> > to apply labels to ramdisk images.
> >
> >> since the rootfs is a ramdisk the changes do not survive a system reboot.
> >>>
> >>> I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.
> >>>
> >> Filesystem labels are not applied when the policy is labeled. On
> >> filesystems that support xattrs, a fs_use_xattr rule is used to tell
> >> SELinux to use the label stored in the security.selinux xattrs, but
> >> the filesystem will still have to be labeled initially. If the fs does
> >> not support xattrs and every file can be labeled the same, then a
> >> genfscon rule can be used.
> >>
> >> I am not sure of your exact case, but you can find more information in
> >> the SELinux Notebook - See
> >> https://github.com/SELinuxProject/selinux-notebook
> >>
> >> Jim
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Ian

Re: How to avoid relabeling rootfs at every boot

[Ian M]

Thanks again, this is all very helpful.

One point is that while the cpio format does not support extended attributes the actual ram disk that is mounted by Linux does.   Not sure if that changes your answer any.

Thanks,

Ian

> On Oct 23, 2020, at 6:37 PM, William Roberts <bill.c.roberts@gmail.com> wrote:
> 
> On Fri, Oct 23, 2020 at 5:20 PM Ian M <merinian@gmail.com> wrote:
>> 
>> Thanks, cpio supporting extended attributes would be very helpful right now.
>> 
>> After looking through the ref policy I see there is a genfscon statement for rootfs which is what is labeling everything as root_t.
> 
> Yeah, genfscon is the way to say, hey this filesystem, all things have
> this label. genfscon takes paths, for more specific labelling,
> IIRC, cannot be used on rootfs; that feature only works for proc/sysfs
> like pseudo filesystems.
> 
>> 
>> Would I break everything terribly if I removed that and setup an fs_use_xattr for the rootfs?
> 
> Yes because there is no xattr support, so it would choke and die when
> the kernel wants the xattr.
> 
> Here's some other things to consider:
> 1. There is no xattr support. You would need to see if that patch or
> something equivalent was accepted and then what kernel
>    version, and determine if your kernel supports it. Then at build
> time for the image you would have to create that dotfile that contains
> the
>    labels and package it in the CPIO archive. Then you could use the
> fs_use_xattr IIUC.
> 2. I could be mistaken, but I think in recent years I have seen
> patches or articles that other FS types can be used for the initial
> root filesystem
>    now without a need for initrd, so you could, IIUC, boot directly
> into a labelled ext4 filesystem. You would have to label that file
> system during build.
> 3. Most linuxt things boot into an initrd and then pivot to the actual
> root filesystem, you could do that as well.
> 
> This would take some digging likely to figure out, or find someone
> that knows way more than me. That shouldn't be too terribly hard,
> I don't know much.
> 
>> 
>> 
>> Thanks,
>> 
>> Ian Merin
>> 
>>>> On Oct 23, 2020, at 3:49 PM, William Roberts <bill.c.roberts@gmail.com> wrote:
>>> 
>>> On Fri, Oct 23, 2020 at 2:05 PM James Carter <jwcart2@gmail.com> wrote:
>>>> 
>>>>> On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@gmail.com> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> I hope this is the right list for this question:
>>>>> 
>>>>> I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but
>>> 
>>> IIRC, when I worked on the Android integration we had to do the same
>>> thing. Android comes with it's own init in the ramdisk, so we just
>>> called restorecon on the parts of
>>> ramdisk that were of interest within the init daemon codebase itself.
>>> I don't think theirs anyway around that IIRC as the CPIO archive
>>> doesn't support xattrs.
>>> 
>>> I do recall seeing this patchset:
>>> https://lwn.net/Articles/788922/
>>> 
>>> I didn't look much into it, but if that got merged, you might be able
>>> to apply labels to ramdisk images.
>>> 
>>>> since the rootfs is a ramdisk the changes do not survive a system reboot.
>>>>> 
>>>>> I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.
>>>>> 
>>>> Filesystem labels are not applied when the policy is labeled. On
>>>> filesystems that support xattrs, a fs_use_xattr rule is used to tell
>>>> SELinux to use the label stored in the security.selinux xattrs, but
>>>> the filesystem will still have to be labeled initially. If the fs does
>>>> not support xattrs and every file can be labeled the same, then a
>>>> genfscon rule can be used.
>>>> 
>>>> I am not sure of your exact case, but you can find more information in
>>>> the SELinux Notebook - See
>>>> https://github.com/SELinuxProject/selinux-notebook
>>>> 
>>>> Jim
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Ian

Re: How to avoid relabeling rootfs at every boot

[William Roberts]

On Fri, Oct 23, 2020 at 5:40 PM Ian M <merinian@gmail.com> wrote:
>
> Thanks again, this is all very helpful.
>
> One point is that while the cpio format does not support extended attributes the actual ram disk that is mounted by Linux does.   Not sure if that changes your answer any.

No because you need to populate the xattrs before the filesystem is
mounted and files are accessed. SELinux needs that information
*before* anything is allowed to happen.
The genfscon statement provides that initial label since the
filesystem is absent. So labelling for prebuilt images is usually done
during build time or paying the cost of a
restorecon at boot. In this case, everyboot since it doesn't persist.

>
> Thanks,
>
> Ian
>
> > On Oct 23, 2020, at 6:37 PM, William Roberts <bill.c.roberts@gmail.com> wrote:
> >
> > On Fri, Oct 23, 2020 at 5:20 PM Ian M <merinian@gmail.com> wrote:
> >>
> >> Thanks, cpio supporting extended attributes would be very helpful right now.
> >>
> >> After looking through the ref policy I see there is a genfscon statement for rootfs which is what is labeling everything as root_t.
> >
> > Yeah, genfscon is the way to say, hey this filesystem, all things have
> > this label. genfscon takes paths, for more specific labelling,
> > IIRC, cannot be used on rootfs; that feature only works for proc/sysfs
> > like pseudo filesystems.
> >
> >>
> >> Would I break everything terribly if I removed that and setup an fs_use_xattr for the rootfs?
> >
> > Yes because there is no xattr support, so it would choke and die when
> > the kernel wants the xattr.
> >
> > Here's some other things to consider:
> > 1. There is no xattr support. You would need to see if that patch or
> > something equivalent was accepted and then what kernel
> >    version, and determine if your kernel supports it. Then at build
> > time for the image you would have to create that dotfile that contains
> > the
> >    labels and package it in the CPIO archive. Then you could use the
> > fs_use_xattr IIUC.
> > 2. I could be mistaken, but I think in recent years I have seen
> > patches or articles that other FS types can be used for the initial
> > root filesystem
> >    now without a need for initrd, so you could, IIUC, boot directly
> > into a labelled ext4 filesystem. You would have to label that file
> > system during build.
> > 3. Most linuxt things boot into an initrd and then pivot to the actual
> > root filesystem, you could do that as well.
> >
> > This would take some digging likely to figure out, or find someone
> > that knows way more than me. That shouldn't be too terribly hard,
> > I don't know much.
> >
> >>
> >>
> >> Thanks,
> >>
> >> Ian Merin
> >>
> >>>> On Oct 23, 2020, at 3:49 PM, William Roberts <bill.c.roberts@gmail.com> wrote:
> >>>
> >>> On Fri, Oct 23, 2020 at 2:05 PM James Carter <jwcart2@gmail.com> wrote:
> >>>>
> >>>>> On Fri, Oct 23, 2020 at 12:02 PM Ian M <merinian@gmail.com> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> I hope this is the right list for this question:
> >>>>>
> >>>>> I've got an embedded system that uses its initramfs as its root filesystem as well.  At boot, after the selinux policy loads, everything on the rootfs is incorrectly labeled as system_u:object_r:root_t.   I have temporarily worked around this by adding a restorecon on the rootfs at boot, but
> >>>
> >>> IIRC, when I worked on the Android integration we had to do the same
> >>> thing. Android comes with it's own init in the ramdisk, so we just
> >>> called restorecon on the parts of
> >>> ramdisk that were of interest within the init daemon codebase itself.
> >>> I don't think theirs anyway around that IIRC as the CPIO archive
> >>> doesn't support xattrs.
> >>>
> >>> I do recall seeing this patchset:
> >>> https://lwn.net/Articles/788922/
> >>>
> >>> I didn't look much into it, but if that got merged, you might be able
> >>> to apply labels to ramdisk images.
> >>>
> >>>> since the rootfs is a ramdisk the changes do not survive a system reboot.
> >>>>>
> >>>>> I may be incorrect, but my understanding (assumption?) is that the labels would be applied when the policy is loaded at boot.  So I cannot understand why the labels are always incorrect.
> >>>>>
> >>>> Filesystem labels are not applied when the policy is labeled. On
> >>>> filesystems that support xattrs, a fs_use_xattr rule is used to tell
> >>>> SELinux to use the label stored in the security.selinux xattrs, but
> >>>> the filesystem will still have to be labeled initially. If the fs does
> >>>> not support xattrs and every file can be labeled the same, then a
> >>>> genfscon rule can be used.
> >>>>
> >>>> I am not sure of your exact case, but you can find more information in
> >>>> the SELinux Notebook - See
> >>>> https://github.com/SELinuxProject/selinux-notebook
> >>>>
> >>>> Jim
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Ian

Re: How to avoid relabeling rootfs at every boot

[Ashish Mishra]

Hi All ,

I am evaluating a use case of  SELINUX + RAMFS scenario & came across
this thread.

Can team please provide pointer on :
a) Use of TMPFS over RAMFS for initramfs
    As that would allow use of "fs_use_xattr"  and hence restorecon
would not be required with "REFPOLICY"
    Am I correct in my understanding here or am I missing any aspect ?

b) Team input / comment on https://lwn.net/Articles/745260/
     patch to extend initramfs archive format to support xattrs

c) Any standard way / location to derive "dependent packages " that
should be present
    on ROOTFS before trying to build ref-policy from
"https://github.com/TresysTechnology/refpolicy"

Thanks ,
Ashish Kumar Mishra

Re: How to avoid relabeling rootfs at every boot

[Paul Moore]

On Tue, Oct 27, 2020 at 7:13 AM Ashish Mishra <ashishm@mvista.com> wrote:
> Hi All ,
>
> I am evaluating a use case of  SELINUX + RAMFS scenario & came across
> this thread.
>
> Can team please provide pointer on :
> a) Use of TMPFS over RAMFS for initramfs
>     As that would allow use of "fs_use_xattr"  and hence restorecon
> would not be required with "REFPOLICY"
>     Am I correct in my understanding here or am I missing any aspect ?

I'm not sure how you would use tpmfs as an initramfs as it is not a
persistent filesystem.  Perhaps there is a way to use a tmpfs as an
initramfs but I don't know how that would would work.

> b) Team input / comment on https://lwn.net/Articles/745260/
>      patch to extend initramfs archive format to support xattrs

I'm not sure how useful that would be in practice as you would still
need to load a SELinux policy before you could actually enforce any
security policy with those labels/xattrs.  We have recently added
support to manage filesystem labels when a policy isn't loaded; the
main motivation was to allow different use cases where the root
filesystem was created and labeled dynamically by the initramfs.

* https://www.paul-moore.com/blog/d/2020/01/linux_v55.html
* https://www.paul-moore.com/blog/d/2020/10/linux_v59.html

> c) Any standard way / location to derive "dependent packages " that
> should be present
>     on ROOTFS before trying to build ref-policy from
> "https://github.com/TresysTechnology/refpolicy"

Reference policy is now located at the repo below.  Generally the
SELinux policy is built offline on a build system and the resulting
SELinux policy binary artifact is loaded at runtime; building the
reference policy from source during boot would likely slow the boot
process dramatically.

* https://github.com/SELinuxProject/refpolicy

-- 
paul moore
www.paul-moore.com