Since cil doesn't store module name and module version in module itself,
there's no simple way how to compare that installed module is the same
version as the module which is supposed to be installed. Even though the
version was not used by semodule itself, it was apparently used by some
team.
With `semodule -l --checksum` users get SHA256 hashes of modules and
could compare them with their files which is faster than installing
modules again and again.
E.g.
# time (
semodule -l --checksum | grep localmodule
/usr/libexec/selinux/hll/pp localmodule.pp | sha256sum
)
localmodule db002f64ddfa3983257b42b54da7b182c9b2e476f47880ae3494f9099e1a42bd
db002f64ddfa3983257b42b54da7b182c9b2e476f47880ae3494f9099e1a42bd -
real 0m0.876s
user 0m0.849s
sys 0m0.028s
vs
# time semodule -i localmodule.pp
real 0m6.147s
user 0m5.800s
sys 0m0.231s
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Acked-by: James Carter <jwcart2@gmail.com>
Use the newly introduced selinux_restorecon_parallel(3) in
setfiles/restorecon and a -T option to both to allow enabling parallel
relabeling. The default behavior without specifying the -T option is to
use 1 thread; parallel relabeling must be requested explicitly by
passing -T 0 (which will use as many threads as there are available CPU
cores) or -T <N>, which will use <N> threads.
=== Benchmarks ===
As measured on a 32-core cloud VM with Fedora 34. Not a fully
representative environment, but still the scaling is quite good.
WITHOUT PATCHES:
$ time restorecon -rn /usr
real 0m21.689s
user 0m21.070s
sys 0m0.494s
WITH PATCHES:
$ time restorecon -rn /usr
real 0m23.940s
user 0m23.127s
sys 0m0.653s
$ time restorecon -rn -T 2 /usr
real 0m13.145s
user 0m25.306s
sys 0m0.695s
$ time restorecon -rn -T 4 /usr
real 0m7.559s
user 0m28.470s
sys 0m1.099s
$ time restorecon -rn -T 8 /usr
real 0m5.186s
user 0m37.450s
sys 0m2.094s
$ time restorecon -rn -T 16 /usr
real 0m3.831s
user 0m51.220s
sys 0m4.895s
$ time restorecon -rn -T 32 /usr
real 0m2.650s
user 1m5.136s
sys 0m6.614s
Note that the benchmarks were performed in read-only mode (-n), so the
labels were only read and looked up in the database, not written. When
fixing labels on a heavily mislabeled system, the scaling would likely
be event better, since a larger % of work could be done in parallel.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Use string literal as format string so that compilers can validate the
count and types of the inherent arguments.
sestatus.c: In function ‘printf_tab’:
sestatus.c:175:16: error: format not a string literal, argument types not checked [-Werror=format-nonliteral]
175 | printf(buf, outp);
| ^~~
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
The code doesn't check the default priority, it just looks for the
highest.
Fixes:
# semodule -E testmodule
Module 'testmodule' does not exist at the default priority '400'. Extracting at highest existing priority '400'.
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Acked-by: James Carter <jwcart2@gmail.com>
In case lstat(3) fails the memory is not free'd at the end of the for
loop, due to the control flow change by continue.
Found by scan-build.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
On Ubuntu 20.04, when building with clang -Werror -Wextra-semi-stmt
(which is not the default build configuration), the compiler reports:
secon.c:686:3: error: empty expression statement has no effect;
remove unnecessary ';' to silence this warning
[-Werror,-Wextra-semi-stmt]
};
^
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
I can't think of a good reason why they should be excluded. On the
contrary, excluding them can cause trouble very easily if some labeling
rules for these directories change. For example, we changed the label
for /dev/nvme* from nvme_device_t to fixed_disk_device_t in Fedora
(updating the allow rules accordingly) and after policy update they
ended up with an invalid context, causing denials.
Thus, remove /dev and /run from the excludes. While there, also add
/root to the basic excludes to match the regex that excludes fc rules
(that should be effectively no functional change).
I did a sanity check on my system by running `restorecon -nv /dev /run`
and it didn't report any label differences.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
Seems to have been there to allow for some sed substitution over the
text. Now that this is gone, the redundant intermediate file can be
removed, too.
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
It is quite useful even to non-privileged users and doesn't require any
privileges to work, except for maybe -v.
Some tools hard code the old path, so a compatibility symlink is also
created.
Signed-off-by: Jonathan Hettwer <j2468h@gmail.com>
Acked-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Resolve pathname before selinux_restorecon_xattr() to prevent problems
with 'No Match' when relative path is used.
Fixes:
# restorecon_xattr -v tmp
...
tmp Digest: f9cd2da7141068bd2c08bc02fa471db63ac7d44c No Match
# restorecon_xattr -v `pwd`/tmp
...
/root/tmp Digest: f9cd2da7141068bd2c08bc02fa471db63ac7d44c Match
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Mention the supported file systems ext4, gfs2 and btrfs.
The options check and verify are interchangeable, merge their
description.
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
Suggested-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Acked-by: Nicolas Iooss <nicolas.iooss@m4x.org>
`setfiles -d` doesn't have any impact on number of errors before it
aborts. It always aborts on first invalid context in spec file.
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Commit 602347c742 ("policycoreutils: setfiles - Modify to use
selinux_restorecon") changed behavior of setfiles. Original
implementation skipped files which it couldn't set context to while the
new implementation aborts on them. setfiles should abort only if it
can't validate a context from spec_file.
Reproducer:
# mkdir -p r/1 r/2 r/3
# touch r/1/1 r/2/1
# chattr +i r/2/1
# touch r/3/1
# setfiles -r r -v /etc/selinux/targeted/contexts/files/file_contexts r
Relabeled r from unconfined_u:object_r:mnt_t:s0 to unconfined_u:object_r:root_t:s0
Relabeled r/2 from unconfined_u:object_r:mnt_t:s0 to unconfined_u:object_r:default_t:s0
setfiles: Could not set context for r/2/1: Operation not permitted
r/3 and r/1 are not relabeled.
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Compilation of newrole with PAM and audit support currently requires that you have the respective headers installed on the host. Instead make the header location customizable to accomodate cross-compilation.
Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
By bind mounting every filesystem we want to relabel we can access all
files without anything hidden due to active mounts.
This comes at the cost of user experience, because setfiles only
displays the percentage if no path is given or the path is /
Signed-off-by: Jonathan Hettwer <j2468h@gmail.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
The -c option allows to check the validity of contexts against a
specified binary policy. Its use is restricted: no pathname can be used
when a binary policy is given to setfiles. It's not clear if this is
intentional as the built-in help and the man page are not stating the
same thing about this (the man page document -c as a normal option,
while the built-in help shows it is restricted).
When generating full system images later used with SELinux in enforcing
mode, the extended attributed of files have to be set by the build
machine. The issue is setfiles always checks the contexts against a
policy (ctx_validate = 1) and using an external binary policy is not
currently possible when using a pathname. This ends up in setfiles
failing early as the contexts of the target image are not always
compatible with the ones of the build machine.
This patch reworks a check on optind only made when -c is used, that
enforced the use of a single argument to allow 1+ arguments, allowing to
use setfiles with an external binary policy and pathnames. The following
command is then allowed, as already documented in the man page:
$ setfiles -m -r target/ -c policy.32 file_contexts target/
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
One thing that confused me when investigating
https://github.com/SELinuxProject/selinux/issues/248 (i.e.
https://github.com/coreos/fedora-coreos-tracker/issues/512) was that the
manual page for `setfiles` seemed to imply that paths were fully
resolved. This was consistent with the issues above where `setfiles` was
failing because the target of the symbolic link didn't exist.
But in fact, the wording around symbolic links in
`setfiles`/`restorecon` refers actually to whether the parent
directories are canonicalized via `realpath(3)` before labeling.
Clarify the man pages to explain this.
Signed-off-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
In case there are errors when committing changes to booleans, the
errors may not be reported to user except by nonzero exit status. With
"setsebool -V" it's possible to see errors from commit phase, but
otherwise the unfixed command is silent:
# setsebool -V -P secure_mode_insmod=off
libsemanage.semanage_install_final_tmp: Could not copy /var/lib/selinux/final/default/contexts/files/file_contexts to /etc/selinux/default/contexts/files/file_contexts. (Read-only file system).
libsemanage.semanage_install_final_tmp: Could not copy /var/lib/selinux/final/default/contexts/files/file_contexts to /etc/selinux/default/contexts/files/file_contexts. (Read-only file system).
Fixed version alerts the user about problems even without -V:
# setsebool -P secure_mode_insmod=off
Failed to commit changes to booleans: Read-only file system
Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
Follow-up of: 9eb9c93275 ("Get rid of security_context_t and fix const declarations.")
Acked-by: William Roberts <william.c.roberts@intel.com>
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
hashtab_replace() and hashtab_map_remove_on_error() aren't used
anywhere, no need to keep them around...
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
When starting restorecond without any option the following redundant
console log is outputed:
/dev/log 100.0%
/var/volatile/run/syslogd.pid 100.0%
...
This is caused by two global variables of same name r_opts. When
executes r_opts = opts in restore_init(), it originally intends
to assign the address of struct r_opts in "restorecond.c" to the
pointer *r_opts in "restore.c".
However, the address is assigned to the struct r_opts and covers
the value of low eight bytes in it. That causes unexpected value
of member varibale 'nochange' and 'verbose' in struct r_opts, thus
affects value of 'restorecon_flags' and executes unexpected operations
when restorecon the files such as the redundant console log output or
file label nochange.
Cause restorecond/restore.c is copied from policycoreutils/setfiles,
which share the same pattern. It also has potential risk to generate
same problems, So fix it in case.
Signed-off-by: Baichuan Kong <kongbaichuan@huawei.com>
semodule -v will turn on semodule's own verbose logging but not logging
from CIL. This change makes the verbose flag also set cil's log level.
By default (ie no -v flag), this will enable CIL_ERR, and each -v will
increase the level from there.
Tested with a duplicated fcontext in the policy.
Before this change:
# semodule -v -B
Committing changes:
Problems processing filecon rules
Failed post db handling
semodule: Failed!
After this change:
# semodule -v -B
[ ... snip ... ]
Found conflicting filecon rules
at /var/lib/selinux/mcs/tmp/modules/400/mycustom/cil:159
at /var/lib/selinux/mcs/tmp/modules/400/mycustom/cil:158
Problems processing filecon rules
Failed post db handling
semodule: Failed!
Closes: https://github.com/SELinuxProject/selinux/issues/176
Signed-off-by: Jason Zaman <jason@perfinion.com>
The previous check used getfilecon to check whether / slash contains a label,
but getfilecon fails only when SELinux is disabled. Therefore it's better to
check this using selinuxenabled.
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Commit 6e289bb7bf ("policycoreutils: fixfiles: remove bad modes of "relabel"
command") added "$RESTORE_MODE" != DEFAULT test when onboot is used. It makes
`fixfiles -B onboot` to show usage instead of updating /.autorelabel
The code is restructured to handle -B for different modes correctly.
Fixes:
# fixfiles -B onboot
Usage: /usr/sbin/fixfiles [-v] [-F] [-f] relabel
...
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
"restorecon -n" (used in the "restore" function) has to be used with
"-v" to display the files whose labels would be changed.
Fixes:
Fixfiles verify does not report misslabelled files unless "-v" option is
used.
Signed-off-by: Vit Mojzis <vmojzis@redhat.com>
Use codespell (https://github.com/codespell-project/codespell) in order
to find many common misspellings that are present in English texts.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
