Go to file
João Marcos Costa 91bf293772 initscripts: fix incompatibility with read-only-rootfs
When the read-only-rootfs feature (in IMAGE_FEATURES) is enabled, the
populate-volatile.sh script runs at build time. This compensates for the
fact that certain essential directories and files cannot be created at
runtime, since the root filesystem is read-only. This is handled in
oe-core's rootfs-postcommands.bbclass, in read_only_rootfs_hook.

However, initscripts-1.0_selinux.inc appends some shell code to
populate-volatile.sh considering it will be run in the target, not on
the host machine. So, if one uses both read-only-rootfs and selinux (in
DISTRO_FEATURES), the recursive call to restorecon is run in the host
machine, since populate-volatile.sh is called in build time. This leads
to errors such as:

| NOTE: Executing read_only_rootfs_hook ...
| DEBUG: Executing shell function read_only_rootfs_hook
| /sbin/restorecon: Could not read /var/lib/AccountsService/users: Permission denied.
| /sbin/restorecon: Could not read /var/lib/NetworkManager: Permission denied.
| /sbin/restorecon: Could not read /var/lib/bluetooth: Permission denied.
| /sbin/restorecon: Could not read /var/lib/chrony: Permission denied.

As a matter of fact, this scenario is a fair reminder not to call
bitbake with sudo.

This change makes sure the append is only performed if the
read-only-rootfs feature is not used.

Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com>
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
2025-10-08 18:52:07 +08:00
classes selinux-image.bbclass: refactor bbclass 2023-10-12 10:14:19 -04:00
conf Set compatible layers to whinlatter 2025-06-26 11:45:50 +08:00
dynamic-layers/networking-layer/recipes-daemons/iscsi-initiator-utils python2: drop bbappend 2021-08-29 21:34:22 -04:00
recipes-connectivity openssh: use config snippet instead of file 2025-09-18 10:22:56 +08:00
recipes-core initscripts: fix incompatibility with read-only-rootfs 2025-10-08 18:52:07 +08:00
recipes-devtools/rpm rpm: remove PACKAGECONFIG[selinux] 2024-02-27 12:30:20 -05:00
recipes-extended libpam: drop packageconfig for selinux 2024-12-10 12:39:38 -05:00
recipes-graphics mesa: rename mesa_%.bbappend to mesa.bbappend 2024-08-26 08:16:18 -04:00
recipes-kernel linux-yocto: drop CONFIG_REISERFS_FS_SECURITY 2025-09-15 14:10:57 +08:00
recipes-security refpolicy: upgrade 20250213+git -> 20250923+git 2025-10-01 20:36:39 +08:00
recipes-support classes: drop redundant classes 2021-08-29 21:34:22 -04:00
.gitignore gitignore: add it 2023-03-27 09:34:01 -04:00
MAINTAINERS MAINTAINERS: fix description of section entries 2024-06-26 11:09:53 -04:00
README README: use simpler syntax to enable systemd 2024-08-26 08:11:44 -04:00
SELinux-FAQ SELinux-FAQ: drop debug-tweaks 2024-12-10 12:39:38 -05:00

meta-selinux
============

This layer's purpose is enabling SE Linux support.

The majority of this layers work is accomplished in bbappend files, used to
enable SE Linux support in existing recipes.

A new recipes-security was added.  The purpose of this category is to add
software specific to system security.

Please see the MAINTAINERS file for information on contacting the maintainers
of this layer, as well as instructions for submitting patches.


Dependencies
------------

This layer depends on the openembedded-core metadata and the meta-python and
meta-oe layers from the meta-openembedded repository.


Maintenance
-----------
Please see the MAINTAINERS file for information on contacting the maintainers
of this layer, as well as instructions for submitting patches.


Building the meta-selinux layer
-------------------------------
In order to add selinux support to the poky build this layer should be added
to your projects bblayers.conf file.

By default the selinux components are disabled.  This conforms to the
Yocto Project compatible guideline that indicate that simply including a
layer should not change the system behavior.

In order to use the components in this layer you must add the 'selinux' to the
DISTRO_FEATURES.  In addition to selinux, you should be sure that acl, xattr and
pam are also present.
e.g. DISTRO_FEATURES:append = " acl xattr pam selinux"

You must also specify a preferred provider for the virtual/refpolicy.  The
included policies with this layer are simply reference policies and will need
to be tailored for your environment.  
* Enable the refpolicy-mls:
e.g. PREFERRED_PROVIDER_virtual/refpolicy ?= "refpolicy-mls"


Using different init manager
----------------------------
By default selinux enabled images coming up with "sysvinit" as init manager,
we can use "systemd" as an init manager using below changes to local.conf

* enable systemd as init manager changes to local.conf
INIT_MANAGER = "systemd"


Enable labeling on first boot
----------------------------
By default, the system will label selinux contexts during build. To enable
labeling on first boot. Set FIRST_BOOT_RELABEL to 1 in local.conf:

FIRST_BOOT_RELABEL = "1"


Starting up the system
----------------------
Most likely the reference policy selected will not just work "out of the box".

As always, if you update the reference policy to better work with OpenEmbedded
or Poky configurations, please submit the changes back to the project.

When using 'core-image-selinux', the system will boot and automatically setup
the policy by running the "fixfiles -f -F relabel" for you.  This is
implemented via the 'selinux-autorelabel' recipe.

The 'core-image-selinux-minimal' does not automatically relabel the system.
So you must boot using the parameters "selinux=1 enforcing=0", and then
manually perform the setup.  Running 'fixfiles -f -F relabel' is available
in this configuration.

After logging in you can verify selinux is present using:

$ sestatus

Output should include:
SELinux status:                 enabled
...
Current mode:                   enforcing
...

The above indicates that selinux is currently running, and if you are running
in an enforcing mode or not.


License
-------

All metadata is MIT licensed unless otherwise stated. Source code included
in tree for individual recipes is under the LICENSE stated in each recipe
(.bb file) unless otherwise stated.

This README document is Copyright (C) 2012 Wind River Systems, Inc.