A new (very overdue) release of SELinux Reference Policy is available: https://github.com/SELinuxProject/refpolicy/releases/tag/RELEASE_2_20240226 Notable Changes: * Many systemd updates up to v255. * RPM and dnf fixes * Tighten private key handling for Apache * Many container and kubernetes improvements * Add support for Cilium * Update object class definitions up to io_uring:cmd. * Add additional rules to cloud-init based on sysadm_t. New Modules/Domains: * cockpit Full Changelog: https://github.com/SELinuxProject/refpolicy/compare/RELEASE_2_20231002...RELEASE_2_20240226 -- Chris PeBenito
A new release of SETools is available: https://github.com/SELinuxProject/setools/releases/tag/4.4.4 Changes: * Update for compiling with libsepol 3.6. * Update apol to use fully specified PyQt enums. * Correct minor code lint issues. -- Chris PeBenito
Hello, all: This list has been migrated to the new vger infrastructure. No action is required on your part and there should be no change in how you interact with this list. This message acts as a verification test that the archives are properly updating. If something isn't working or looking right, please reach out to helpdesk@kernel.org. Best regards, -K
On Thu, Oct 19, 2023 at 9:10 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Wed, Oct 18, 2023 at 12:35 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Tue, Oct 17, 2023 at 04:28:53PM -0400, Paul Moore wrote:
> > > Thanks Al.
> > >
> > > Giving this a very quick look, I like the code simplifications that
> > > come out of this change and I'll trust you on the idea that this
> > > approach is better from a VFS perspective.
> > >
> > > While the reject_all() permission hammer is good, I do want to make
> > > sure we are covered from a file labeling perspective; even though the
> > > DAC/reject_all() check hits first and avoids the LSM inode permission
> > > hook, we still want to make sure the files are labeled properly. It
> > > looks like given the current SELinux Reference Policy this shouldn't
> > > be a problem, it will be labeled like most everything else in
> > > selinuxfs via genfscon (SELinux policy construct). I expect those
> > > with custom SELinux policies will have something similar in place with
> > > a sane default that would cover the /sys/fs/selinux/.swapover
> > > directory but I did add the selinux-refpol list to the CC line just in
> > > case I'm being dumb and forgetting something important with respect to
> > > policy.
> > >
> > > The next step is to actually boot up a kernel with this patch and make
> > > sure it doesn't break anything. Simply booting up a SELinux system
> > > and running 'load_policy' a handful of times should exercise the
> > > policy (re)load path, and if you want a (relatively) simple SELinux
> > > test suite you can find one here:
> > >
> > > * https://github.com/SELinuxProject/selinux-testsuite
> > >
> > > The README.md should have the instructions necessary to get it
> > > running. If you can't do that, and no one else on the mailing list is
> > > able to test this out, I'll give it a go but expect it to take a while
> > > as I'm currently swamped with reviews and other stuff.
> >
> > It does survive repeated load_policy (as well as semodule -d/semodule -e,
> > with expected effect on /booleans, AFAICS). As for the testsuite...
> > No regressions compared to clean -rc5, but then there are (identical)
> > failures on both - "Failed 8/76 test programs. 88/1046 subtests failed."
> > Incomplete defconfig, at a guess...
>
> All tests passed for me using the defconfig fragment from the selinux-testsuite.
I just merged this into selinux/dev, thanks everyone.
--
paul-moore.com
On Wed, Oct 18, 2023 at 12:35 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Tue, Oct 17, 2023 at 04:28:53PM -0400, Paul Moore wrote:
> > Thanks Al.
> >
> > Giving this a very quick look, I like the code simplifications that
> > come out of this change and I'll trust you on the idea that this
> > approach is better from a VFS perspective.
> >
> > While the reject_all() permission hammer is good, I do want to make
> > sure we are covered from a file labeling perspective; even though the
> > DAC/reject_all() check hits first and avoids the LSM inode permission
> > hook, we still want to make sure the files are labeled properly. It
> > looks like given the current SELinux Reference Policy this shouldn't
> > be a problem, it will be labeled like most everything else in
> > selinuxfs via genfscon (SELinux policy construct). I expect those
> > with custom SELinux policies will have something similar in place with
> > a sane default that would cover the /sys/fs/selinux/.swapover
> > directory but I did add the selinux-refpol list to the CC line just in
> > case I'm being dumb and forgetting something important with respect to
> > policy.
> >
> > The next step is to actually boot up a kernel with this patch and make
> > sure it doesn't break anything. Simply booting up a SELinux system
> > and running 'load_policy' a handful of times should exercise the
> > policy (re)load path, and if you want a (relatively) simple SELinux
> > test suite you can find one here:
> >
> > * https://github.com/SELinuxProject/selinux-testsuite
> >
> > The README.md should have the instructions necessary to get it
> > running. If you can't do that, and no one else on the mailing list is
> > able to test this out, I'll give it a go but expect it to take a while
> > as I'm currently swamped with reviews and other stuff.
>
> It does survive repeated load_policy (as well as semodule -d/semodule -e,
> with expected effect on /booleans, AFAICS). As for the testsuite...
> No regressions compared to clean -rc5, but then there are (identical)
> failures on both - "Failed 8/76 test programs. 88/1046 subtests failed."
> Incomplete defconfig, at a guess...
All tests passed for me using the defconfig fragment from the selinux-testsuite.
On Wed, Oct 18, 2023 at 12:35 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Oct 17, 2023 at 04:28:53PM -0400, Paul Moore wrote:
> > Thanks Al.
> >
> > Giving this a very quick look, I like the code simplifications that
> > come out of this change and I'll trust you on the idea that this
> > approach is better from a VFS perspective.
> >
> > While the reject_all() permission hammer is good, I do want to make
> > sure we are covered from a file labeling perspective; even though the
> > DAC/reject_all() check hits first and avoids the LSM inode permission
> > hook, we still want to make sure the files are labeled properly. It
> > looks like given the current SELinux Reference Policy this shouldn't
> > be a problem, it will be labeled like most everything else in
> > selinuxfs via genfscon (SELinux policy construct). I expect those
> > with custom SELinux policies will have something similar in place with
> > a sane default that would cover the /sys/fs/selinux/.swapover
> > directory but I did add the selinux-refpol list to the CC line just in
> > case I'm being dumb and forgetting something important with respect to
> > policy.
> >
> > The next step is to actually boot up a kernel with this patch and make
> > sure it doesn't break anything. Simply booting up a SELinux system
> > and running 'load_policy' a handful of times should exercise the
> > policy (re)load path, and if you want a (relatively) simple SELinux
> > test suite you can find one here:
> >
> > * https://github.com/SELinuxProject/selinux-testsuite
> >
> > The README.md should have the instructions necessary to get it
> > running. If you can't do that, and no one else on the mailing list is
> > able to test this out, I'll give it a go but expect it to take a while
> > as I'm currently swamped with reviews and other stuff.
>
> It does survive repeated load_policy (as well as semodule -d/semodule -e,
> with expected effect on /booleans, AFAICS). As for the testsuite...
> No regressions compared to clean -rc5, but then there are (identical)
> failures on both - "Failed 8/76 test programs. 88/1046 subtests failed."
> Incomplete defconfig, at a guess...
Thanks for the smoke testing, the tests should run clean, but if you
didn't adjust the Kconfig you're likely correct that it is the source
of the failures. I'll build a kernel with the patch and give it a
test.
From what I can see, it doesn't look like this is a candidate for
stable, correct?
--
paul-moore.com
On Tue, Oct 17, 2023 at 04:28:53PM -0400, Paul Moore wrote:
> Thanks Al.
>
> Giving this a very quick look, I like the code simplifications that
> come out of this change and I'll trust you on the idea that this
> approach is better from a VFS perspective.
>
> While the reject_all() permission hammer is good, I do want to make
> sure we are covered from a file labeling perspective; even though the
> DAC/reject_all() check hits first and avoids the LSM inode permission
> hook, we still want to make sure the files are labeled properly. It
> looks like given the current SELinux Reference Policy this shouldn't
> be a problem, it will be labeled like most everything else in
> selinuxfs via genfscon (SELinux policy construct). I expect those
> with custom SELinux policies will have something similar in place with
> a sane default that would cover the /sys/fs/selinux/.swapover
> directory but I did add the selinux-refpol list to the CC line just in
> case I'm being dumb and forgetting something important with respect to
> policy.
>
> The next step is to actually boot up a kernel with this patch and make
> sure it doesn't break anything. Simply booting up a SELinux system
> and running 'load_policy' a handful of times should exercise the
> policy (re)load path, and if you want a (relatively) simple SELinux
> test suite you can find one here:
>
> * https://github.com/SELinuxProject/selinux-testsuite
>
> The README.md should have the instructions necessary to get it
> running. If you can't do that, and no one else on the mailing list is
> able to test this out, I'll give it a go but expect it to take a while
> as I'm currently swamped with reviews and other stuff.
It does survive repeated load_policy (as well as semodule -d/semodule -e,
with expected effect on /booleans, AFAICS). As for the testsuite...
No regressions compared to clean -rc5, but then there are (identical)
failures on both - "Failed 8/76 test programs. 88/1046 subtests failed."
Incomplete defconfig, at a guess...
On Mon, Oct 16, 2023 at 6:08 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > [ > That thing sits in viro/vfs.git#work.selinuxfs; I have > lock_rename()-related followups in another branch, so a pull would be more > convenient for me than cherry-pick. NOTE: testing and comments would > be very welcome - as it is, the patch is pretty much untested beyond > "it builds". > ] > > On policy reload selinuxfs replaces two subdirectories (/booleans > and /class) with new variants. Unfortunately, that's done with > serious abuses of directory locking. > > 1) lock_rename() should be done to parents, not to objects being > exchanged > > 2) there's a bunch of reasons why it should not be done for directories > that do not have a common ancestor; most of those do not apply to > selinuxfs, but even in the best case the proof is subtle and brittle. > > 3) failure halfway through the creation of /class will leak > names and values arrays. > > 4) use of d_genocide() is also rather brittle; it's probably not much of > a bug per se, but e.g. an overmount of /sys/fs/selinuxfs/classes/shm/index > with any regular file will end up with leaked mount on policy reload. > Sure, don't do it, but... > > Let's stop messing with disconnected directories; just create > a temporary (/.swapover) with no permissions for anyone (on the > level of ->permission() returing -EPERM, no matter who's calling > it) and build the new /booleans and /class in there; then > lock_rename on root and that temporary directory and d_exchange() > old and new both for class and booleans. Then unlock and use > simple_recursive_removal() to take the temporary out; it's much > more robust. > > And instead of bothering with separate pathways for freeing > new (on failure halfway through) and old (on success) names/values, > do all freeing in one place. With temporaries swapped with the > old ones when we are past all possible failures. > > The only user-visible difference is that /.swapover shows up > (but isn't possible to open, look up into, etc.) for the > duration of policy reload. Thanks Al. Giving this a very quick look, I like the code simplifications that come out of this change and I'll trust you on the idea that this approach is better from a VFS perspective. While the reject_all() permission hammer is good, I do want to make sure we are covered from a file labeling perspective; even though the DAC/reject_all() check hits first and avoids the LSM inode permission hook, we still want to make sure the files are labeled properly. It looks like given the current SELinux Reference Policy this shouldn't be a problem, it will be labeled like most everything else in selinuxfs via genfscon (SELinux policy construct). I expect those with custom SELinux policies will have something similar in place with a sane default that would cover the /sys/fs/selinux/.swapover directory but I did add the selinux-refpol list to the CC line just in case I'm being dumb and forgetting something important with respect to policy. The next step is to actually boot up a kernel with this patch and make sure it doesn't break anything. Simply booting up a SELinux system and running 'load_policy' a handful of times should exercise the policy (re)load path, and if you want a (relatively) simple SELinux test suite you can find one here: * https://github.com/SELinuxProject/selinux-testsuite The README.md should have the instructions necessary to get it running. If you can't do that, and no one else on the mailing list is able to test this out, I'll give it a go but expect it to take a while as I'm currently swamped with reviews and other stuff. -- paul-moore.com
A new (very overdue) release of SELinux Reference Policy is available: https://github.com/SELinuxProject/refpolicy/releases/tag/RELEASE_2_20231002 Notable Changes: * Several Gentoo fixes ported from Gentoo policy * Fixes for containerd/docker * Move excessive capabilities in container_t to tunables. * Various systemd updates and fixes * Updated object class/permission definitions for recent kernels * Add support for systemd memory pressure notifications protocol * Xscreensaver updates for their newest release * Remove interfaces deprecated before 2021 * Add tunables to control network access in: * *_dbusd_t * pulseaudio_t * spamc_t * syslogd_t * xdm_t * xserver_t New Modules/Domains: * crio * eg25manager * iiosensorproxy * kubernetes * lomemorymonitor * powerprofiles * rasdaemon * switcheroo * systemd-pcrphrase * thunderbolt Full Changelog: https://github.com/SELinuxProject/refpolicy/compare/RELEASE_2_20221101...RELEASE_2_20231002 -- Chris PeBenito
On 9/30/2023 7:55 AM, Russell Coker wrote: > Why do we have the pattern append_lnk_files_pattern? It's not used anywhere > in refpolicy along with write_lnk_files_pattern. The sesearch command shows > only the following uses of append permission for lnk_file. More than likely it's simply a copy-paste when I first generated the macros. > # sesearch -A -c lnk_file -p append > allow files_unconfined_type file_type:lnk_file { append create execmod execute > getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto > rename setattr unlink watch write }; > allow filesystem_unconfined_type filesystem_type:lnk_file { append create > execmod execute getattr ioctl link lock map mounton open quotaon read > relabelfrom relabelto rename setattr unlink watch write }; > allow kern_unconfined proc_type:lnk_file { append create execmod execute > getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto > rename setattr unlink watch write }; > allow kern_unconfined unlabeled_t:lnk_file { append create execmod execute > getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto > rename setattr unlink watch write }; > > I guess that the kern_unconfined stuff is related to the magic symlinks in / > proc/PID directories. Is there any other way where a symlink can be appended? > > Does it make sense to have the append macros and the write macros with append > permission included? The way I see it (and how the various perm macros are designed), if a rule has write, then append is also implied. Append may not make sense for lnk_file, but I don't see a downside to having it. -- Chris PeBenito
Why do we have the pattern append_lnk_files_pattern? It's not used anywhere in refpolicy along with write_lnk_files_pattern. The sesearch command shows only the following uses of append permission for lnk_file. # sesearch -A -c lnk_file -p append allow files_unconfined_type file_type:lnk_file { append create execmod execute getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr unlink watch write }; allow filesystem_unconfined_type filesystem_type:lnk_file { append create execmod execute getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr unlink watch write }; allow kern_unconfined proc_type:lnk_file { append create execmod execute getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr unlink watch write }; allow kern_unconfined unlabeled_t:lnk_file { append create execmod execute getattr ioctl link lock map mounton open quotaon read relabelfrom relabelto rename setattr unlink watch write }; I guess that the kern_unconfined stuff is related to the magic symlinks in / proc/PID directories. Is there any other way where a symlink can be appended? Does it make sense to have the append macros and the write macros with append permission included? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 9/26/2023 4:09 AM, Russell Coker wrote:
> Regarding /usr/lib/NetworkManager/nm-dispatcher, you asked for more
> information when I submitted a patch changing the context.
>
> Currently it has type NetworkManager_initrc_exec_t which implies that it's
> part of a start script when it's really a program that's doing the actual
> work. Also that type means that when a laptop resumes from suspend it gets
> run in domain initrc_t which is not appropriate for it.
>
> We could have a domain_auto_trans for type NetworkManager_initrc_exec_t but I
> think it's more appropriate to give it a label that more accurately reflects
> it's use.
>
> What do you think Chris?
I agree that NetworkManager_initrc_exec_t doesn't fit. It could warrant
its own domain, like audisp, but I'm unsure without more info about the
types of access it needs. i.e. more specific info than is in the man page.
--
Chris PeBenito
Regarding /usr/lib/NetworkManager/nm-dispatcher, you asked for more information when I submitted a patch changing the context. Currently it has type NetworkManager_initrc_exec_t which implies that it's part of a start script when it's really a program that's doing the actual work. Also that type means that when a laptop resumes from suspend it gets run in domain initrc_t which is not appropriate for it. We could have a domain_auto_trans for type NetworkManager_initrc_exec_t but I think it's more appropriate to give it a label that more accurately reflects it's use. What do you think Chris? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
This adds policy for the firmware update daemon, it updates system BIOS as well as connected devices such as Thunderbolt docks. I think it's ready to merge. Signed-off-by: Russell Coker <russell@coker.com.au> Index: refpolicy-2.20230629/policy/modules/system/fwupd.fc =================================================================== --- /dev/null +++ refpolicy-2.20230629/policy/modules/system/fwupd.fc @@ -0,0 +1,5 @@ +/usr/bin/fwupdmgr -- gen_context(system_u:object_r:fwupd_exec_t,s0) +/usr/libexec/fwupd/fwupd -- gen_context(system_u:object_r:fwupd_exec_t,s0) +/var/lib/fwupd(/.*)? gen_context(system_u:object_r:fwupd_var_lib_t,s0) +/var/cache/fwupd(/.*)? gen_context(system_u:object_r:fwupd_cache_t,s0) +/etc/fwupd(/.*)? gen_context(system_u:object_r:fwupd_conf_t,s0) Index: refpolicy-2.20230629/policy/modules/system/fwupd.if =================================================================== --- /dev/null +++ refpolicy-2.20230629/policy/modules/system/fwupd.if @@ -0,0 +1,29 @@ +## <summary>Policy for firmwate update daemon and utility.</summary> + +######################################## +## <summary> +## Execute fwupd in the user role +## the kmod domain, and use the caller's terminal. +## Has a sigchld backchannel. +## </summary> +## <param name="domain"> +## <summary> +## Domain allowed to transition. +## </summary> +## </param> +## <param name="role"> +## <summary> +## Role allowed access. +## </summary> +## </param> +## <rolecap/> +# +interface(`fwupd_run',` + gen_require(` + attribute_role fwupd_roles; + type fwupd_exec_t, fwupd_t; + ') + + domtrans_pattern($1, fwupd_exec_t, fwupd_t) + roleattribute $2 fwupd_roles; +') Index: refpolicy-2.20230629/policy/modules/system/fwupd.te =================================================================== --- /dev/null +++ refpolicy-2.20230629/policy/modules/system/fwupd.te @@ -0,0 +1,153 @@ +policy_module(fwupd) + + +attribute_role fwupd_roles; +type fwupd_t; +type fwupd_exec_t; +init_daemon_domain(fwupd_t, fwupd_exec_t) +role fwupd_roles types fwupd_t; + +type fwupd_var_lib_t; +files_type(fwupd_var_lib_t) + +type fwupd_cache_t; +files_type(fwupd_cache_t) + +type fwupd_conf_t; +files_type(fwupd_conf_t) + +type fwupd_tmpfs_t; +files_tmpfs_file(fwupd_tmpfs_t) + +type fwupd_runtime_t; +files_runtime_file(fwupd_runtime_t) + +# sys_admin is for "FuPluginUefiCapsule skipping device that failed coldplug: failed to read fw_class" +allow fwupd_t self:capability { dac_override dac_read_search linux_immutable sys_rawio sys_admin }; + +allow fwupd_t self:process { signal getsched setsched }; +allow fwupd_t self:fifo_file { getattr read write }; +allow fwupd_t self:fd use; + +allow fwupd_t self:netlink_kobject_uevent_socket { create getattr setopt bind read }; +sysnet_dns_name_resolve(fwupd_t) +corenet_tcp_connect_generic_port(fwupd_t) +corenet_tcp_connect_http_port(fwupd_t) + +allow fwupd_t fwupd_conf_t:dir { watch list_dir_perms }; +allow fwupd_t fwupd_conf_t:file read_file_perms; + +allow fwupd_t fwupd_var_lib_t:dir { watch manage_dir_perms }; +allow fwupd_t fwupd_var_lib_t:file { manage_file_perms }; + +allow fwupd_t fwupd_cache_t:dir { watch manage_dir_perms }; +allow fwupd_t fwupd_cache_t:file { map manage_file_perms }; + +auth_write_pam_motd_files(fwupd_t) + +fs_tmpfs_filetrans(fwupd_t, fwupd_tmpfs_t, { file }) +allow fwupd_t fwupd_tmpfs_t:file manage_file_perms; + +allow fwupd_t fwupd_runtime_t:file manage_file_perms; + +kernel_read_kernel_sysctls(fwupd_t) +# for /proc/filesystems etc +kernel_read_system_state(fwupd_t) +kernel_read_vm_overcommit_sysctl(fwupd_t) + +dev_getattr_sysfs(fwupd_t) +dev_read_urand(fwupd_t) +dev_read_sysfs(fwupd_t) +dev_rw_cpu_microcode(fwupd_t) +dev_rw_mei_device(fwupd_t) +dev_rw_tpm(fwupd_t) +dev_rw_xserver_misc(fwupd_t) +dev_rx_raw_memory(fwupd_t) + +corecmd_exec_bin(fwupd_t) +corecmd_list_bin(fwupd_t) +corecmd_watch_bin_dirs(fwupd_t) + +dbus_system_bus_client(fwupd_t) +dbus_connect_system_bus(fwupd_t) + +files_map_usr_files(fwupd_t) +files_read_etc_files(fwupd_t) +files_read_etc_symlinks(fwupd_t) +files_read_usr_files(fwupd_t) +files_search_var_lib(fwupd_t) +files_search_boot(fwupd_t) +files_watch_etc_dirs(fwupd_t) +files_watch_usr_dirs(fwupd_t) + +fs_manage_efivarfs_files(fwupd_t) +fs_getattr_dos_fs(fwupd_t) +fs_getattr_efivarfs(fwupd_t) + +fs_manage_dos_dirs(fwupd_t) +fs_manage_dos_files(fwupd_t) +fs_mmap_read_dos_files(fwupd_t) + +init_get_generic_units_status(fwupd_t) +init_get_system_status(fwupd_t) + +# for cgroup file of init_t process +init_read_state(fwupd_t) + +miscfiles_read_generic_certs(fwupd_t) +miscfiles_read_localization(fwupd_t) + +mount_read_runtime_files(fwupd_t) + +selinux_get_enforce_mode(fwupd_t) +selinux_get_fs_mount(fwupd_t) +seutil_search_default_contexts(fwupd_t) + +storage_raw_read_fixed_disk(fwupd_t) + +sysnet_read_config(fwupd_t) + +udev_read_runtime_files(fwupd_t) +userdom_use_user_ptys(fwupd_t) +userdom_use_user_ttys(fwupd_t) +# for dconf +userdom_map_user_tmp_files(fwupd_t) +userdom_rw_user_tmp_files(fwupd_t) +userdom_search_user_runtime_root(fwupd_t) +userdom_search_user_runtime(fwupd_t) + +optional_policy(` + bluetooth_dbus_chat(fwupd_t) +') + +optional_policy(` + devicekit_dbus_chat_disk(fwupd_t) + devicekit_dbus_chat_power(fwupd_t) +') + +optional_policy(` + gpg_exec(fwupd_t) +') + +optional_policy(` + init_dbus_chat(fwupd_t) +') + +optional_policy(` + networkmanager_read_runtime_files(fwupd_t) +') + +optional_policy(` + policykit_dbus_chat(fwupd_t) +') + +optional_policy(` + systemd_dbus_chat_logind(fwupd_t) + systemd_use_logind_fds(fwupd_t) + systemd_write_inherited_logind_inhibit_pipes(fwupd_t) +') + +optional_policy(` + unconfined_dbus_send(fwupd_t) +') + Index: refpolicy-2.20230629/policy/modules/roles/sysadm.te =================================================================== --- refpolicy-2.20230629.orig/policy/modules/roles/sysadm.te +++ refpolicy-2.20230629/policy/modules/roles/sysadm.te @@ -448,6 +448,10 @@ optional_policy(` ') optional_policy(` + fwupd_run(sysadm_t, sysadm_r) +') + +optional_policy(` gatekeeper_admin(sysadm_t, sysadm_r) ') Index: refpolicy-2.20230629/policy/modules/system/unconfined.te =================================================================== --- refpolicy-2.20230629.orig/policy/modules/system/unconfined.te +++ refpolicy-2.20230629/policy/modules/system/unconfined.te @@ -107,6 +107,10 @@ optional_policy(` ') optional_policy(` + fwupd_run(unconfined_t, unconfined_r) +') + +optional_policy(` hadoop_role(unconfined, unconfined_t, unconfined_application_exec_domain, unconfined_r) ') Index: refpolicy-2.20230629/policy/modules/kernel/devices.if =================================================================== --- refpolicy-2.20230629.orig/policy/modules/kernel/devices.if +++ refpolicy-2.20230629/policy/modules/kernel/devices.if @@ -2826,6 +2826,24 @@ interface(`dev_delete_lvm_control_dev',` ######################################## ## <summary> +## Read and write the Intel mei control device. +## </summary> +## <param name="domain"> +## <summary> +## Domain allowed access. +## </summary> +## </param> +# +interface(`dev_rw_mei_device',` + gen_require(` + type device_t, mei_device_t; + ') + + rw_chr_files_pattern($1, device_t, mei_device_t) +') + +######################################## +## <summary> ## dontaudit getattr raw memory devices (e.g. /dev/mem). ## </summary> ## <param name="domain">
Add noatsecure for $1_systemd_t executing $1_dbusd_t because systemd sets important environment variables and dbus-broker aborts with "no media" error otherwise. Tiny patch because this was a pain to track down and is necessary to make Mobian usable. Signed-off-by: Russell Coker <russell@coker.com.au> diff --git a/policy/modules/services/dbus.if b/policy/modules/services/dbus.if index ee497809b..741115a51 100644 --- a/policy/modules/services/dbus.if +++ b/policy/modules/services/dbus.if @@ -113,6 +113,8 @@ template(`dbus_role_template',` optional_policy(` systemd_read_logind_runtime_files($1_dbusd_t) systemd_user_daemon_domain($1, dbusd_exec_t, $1_dbusd_t) + # dbus-broker-launch fails with no media on sd_bus_open_user() without this + systemd_user_daemon_domain_noatsecure($1, $1_dbusd_t) systemd_user_unix_stream_activated_socket($1_dbusd_t, session_dbusd_runtime_t) ') ') diff --git a/policy/modules/system/systemd.if b/policy/modules/system/systemd.if index 77a59c662..0046f1722 100644 --- a/policy/modules/system/systemd.if +++ b/policy/modules/system/systemd.if @@ -229,6 +229,30 @@ template(`systemd_user_daemon_domain',` systemd_user_app_status($1, $3) ') +###################################### +## <summary> +## Allow the specified domain to not have th atsecure setting when started +## as a daemon by the specified systemd user instance +## </summary> +## <param name="prefix"> +## <summary> +## Prefix for the user domain. +## </summary> +## </param> +## <param name="domain"> +## <summary> +## Domain that is entered with noatsecure +## </summary> +## </param> +# +template(`systemd_user_daemon_domain_noatsecure',` + gen_require(` + type $1_systemd_t; + ') + + allow $1_systemd_t $2:process noatsecure; +') + ###################################### ## <summary> ## Associate the specified file type to be a type whose sock files
/usr/share/selinux/devel/include/system/init.if: Syntax error on line 2064 true [type=TRUE] /usr/share/selinux/devel/include/system/init.if: Syntax error on line 2075 ' [type=SQUOTE] /usr/share/selinux/devel/include/system/init.if: Syntax error on line 2079 ' [type=SQUOTE] /usr/share/selinux/devel/include/system/init.if: Syntax error on line 2090 ' [type=SQUOTE] /usr/share/selinux/devel/include/system/init.if: Syntax error on line 2094 ' [type=SQUOTE] /usr/share/selinux/devel/include/kernel/kernel.if: Syntax error on line 1737 - [type=MINUS] /usr/share/selinux/devel/include/kernel/kernel.if: Syntax error on line 1755 - [type=MINUS] I see the above errors when I run sepolgen-ifgen. interface(`init_startstop_service',` ifelse(`init_systemd',`true',` # This ifelse condition is temporary, until # all callers are updated to provide unit files. ifelse(`$5',`',`',` gen_require(` class service { start status stop }; ') allow $1 $5:service { start status stop }; ') ',`distro_gentoo',`true',` # for OpenRC seutil_labeled_init_script_run_runinit($1, $2, $4) ',`direct_sysadm_daemon',`true',` gen_require(` role system_r; ') The first 3 are from the above, the init_systemd, distro_gentoo, and direct_sysadm_daemon macros. https://www.gnu.org/software/m4/manual/html_node/Ifelse.html According to the above web page we shouldn't have quotes around those macros to allow expansion. But removing them gives the following errors: /usr/share/selinux/devel/include/system/init.if: Syntax error on line 2064 init_systemd [type=IDENTIFIER] /usr/share/selinux/devel/include/system/init.if: Syntax error on line 2075 ' [type=SQUOTE] /usr/share/selinux/devel/include/system/init.if: Syntax error on line 2079 ' [type=SQUOTE] The errors about type=MINUS are from the the -proc_type in the following: interface(`kernel_write_non_proc_init_mountpoint_files',` gen_require(` attribute proc_type; ') init_write_mountpoint_files($1, -proc_type) ') Any suggestions on how to address this? My m4 skills aren't up to this task. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
A new release of SETools is available: https://github.com/SELinuxProject/setools/releases/tag/4.4.3 Changes: * Fix compilation with Cython 3.0.0. * Improve man pages. * Remove neverallow options in sediff. * Add -r option to seinfoflow to get flows into the source type. * Reject a rule with no permissions as invalid policy. -- Chris PeBenito
On Fri, 28 Jan 2022 at 02:47, Paul Moore <paul@paul-moore.com> wrote: > > On Thu, Jan 27, 2022 at 8:42 AM Chris PeBenito <pebenito@ieee.org> wrote: > > On 1/26/22 17:51, Paul Moore wrote: > > > On Tue, Jan 25, 2022 at 9:59 AM Christian Göttsche > > > <cgzones@googlemail.com> wrote: > > >> > > >> In case a setuid or setgid binary is mislabeled with a generic context, > > >> either via a policy mistake or a move by the distribution package, > > >> executing it will be checked by the file permission execute_no_trans on > > >> the generic file context (e.g. bin_t). The setuid(2)/setgid(2) syscall > > >> within will then be checked against the unchanged caller process > > >> context, which might have been granted the capability permission setuid/ > > >> setgid to initially drop privileges. To avoid that scenario split the > > >> execute_no_trans permission in case of a setuid/setgid binary into a new > > >> permission execute_sxid_no_trans. > > >> > > >> For backward compatibility this behavior is contained in a new policy > > >> capability. > > >> > > >> Signed-off-by: Christian Göttsche <cgzones@googlemail.com> > > >> --- > > >> security/selinux/hooks.c | 9 ++++++++- > > >> security/selinux/include/classmap.h | 2 +- > > >> security/selinux/include/policycap.h | 1 + > > >> security/selinux/include/policycap_names.h | 3 ++- > > >> security/selinux/include/security.h | 8 ++++++++ > > >> 5 files changed, 20 insertions(+), 3 deletions(-) > > > > > > Adding the refpolicy list to this thread as their opinion seems > > > particularly relevant to this discussion. > > > > > > FWIW, this looks reasonable to me but I would like to hear what others > > > have to say. > > > > I think this a band-aid to cover up the real problem, which is the mislabeled files. > > It's hard to disagree with that, and the kernel is probably the wrong > place to apply a band-aid unless it is the only option left. > Adding a new datapoint to this RFC: An unprivileged user can via the setuid binary newgrp(1) write arbitrary content to files he can open in write mode but not actually write to, e.g. /proc/sys/kernel/ns_last_pid [1]. This also is reproducible on Fedora where /usr/bin/newgrp has the generic context bin_t, so the write (and capable check) happens in the caller context of unconfined_t. With the proposed permission split applied and instead of granting unconfined_t the new permission execute_sxid_no_trans but relying on an intermediate template domain $1_newgrp_t the access would have been denied, due to lack of permissions of the templated newgrp domain. With a generic file type of bin_t newgrp would not be executable for callers otherwise. Most setuid binaries are already labeled with a private type, newgrp and pkexec are the only ones left on a head-less Fedora system. One could still argue this is a policy neglect, but normally policy neglects result in missing permissions and reduced functionality, not in unintended privilege escalation. [1]: https://github.com/shadow-maint/shadow/pull/758 > > >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > > >> index 5b6895e4fc29..b825fee39a70 100644 > > >> --- a/security/selinux/hooks.c > > >> +++ b/security/selinux/hooks.c > > >> @@ -2348,9 +2348,16 @@ static int selinux_bprm_creds_for_exec(struct linux_binprm *bprm) > > >> ad.u.file = bprm->file; > > >> > > >> if (new_tsec->sid == old_tsec->sid) { > > >> + u32 perm; > > >> + > > >> + if (selinux_policycap_execute_sxid_no_trans() && is_sxid(inode->i_mode)) > > >> + perm = FILE__EXECUTE_SXID_NO_TRANS; > > >> + else > > >> + perm = FILE__EXECUTE_NO_TRANS; > > >> + > > >> rc = avc_has_perm(&selinux_state, > > >> old_tsec->sid, isec->sid, > > >> - SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, &ad); > > >> + SECCLASS_FILE, perm, &ad); > > >> if (rc) > > >> return rc; > > >> } else { > > >> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h > > >> index 35aac62a662e..53a1eeeb86fb 100644 > > >> --- a/security/selinux/include/classmap.h > > >> +++ b/security/selinux/include/classmap.h > > >> @@ -65,7 +65,7 @@ struct security_class_mapping secclass_map[] = { > > >> "quotaget", "watch", NULL } }, > > >> { "file", > > >> { COMMON_FILE_PERMS, > > >> - "execute_no_trans", "entrypoint", NULL } }, > > >> + "execute_no_trans", "entrypoint", "execute_sxid_no_trans", NULL } }, > > >> { "dir", > > >> { COMMON_FILE_PERMS, "add_name", "remove_name", > > >> "reparent", "search", "rmdir", NULL } }, > > >> diff --git a/security/selinux/include/policycap.h b/security/selinux/include/policycap.h > > >> index 2ec038efbb03..23929dc3e1db 100644 > > >> --- a/security/selinux/include/policycap.h > > >> +++ b/security/selinux/include/policycap.h > > >> @@ -11,6 +11,7 @@ enum { > > >> POLICYDB_CAPABILITY_CGROUPSECLABEL, > > >> POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION, > > >> POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS, > > >> + POLICYDB_CAPABILITY_EXECUTE_SXID_NO_TRANS, > > >> __POLICYDB_CAPABILITY_MAX > > >> }; > > >> #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1) > > >> diff --git a/security/selinux/include/policycap_names.h b/security/selinux/include/policycap_names.h > > >> index b89289f092c9..4c014c2cf352 100644 > > >> --- a/security/selinux/include/policycap_names.h > > >> +++ b/security/selinux/include/policycap_names.h > > >> @@ -12,7 +12,8 @@ const char *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = { > > >> "always_check_network", > > >> "cgroup_seclabel", > > >> "nnp_nosuid_transition", > > >> - "genfs_seclabel_symlinks" > > >> + "genfs_seclabel_symlinks", > > >> + "execute_sxid_no_trans", > > >> }; > > >> > > >> #endif /* _SELINUX_POLICYCAP_NAMES_H_ */ > > >> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h > > >> index ac0ece01305a..ab95241b6b7b 100644 > > >> --- a/security/selinux/include/security.h > > >> +++ b/security/selinux/include/security.h > > >> @@ -219,6 +219,14 @@ static inline bool selinux_policycap_genfs_seclabel_symlinks(void) > > >> return READ_ONCE(state->policycap[POLICYDB_CAPABILITY_GENFS_SECLABEL_SYMLINKS]); > > >> } > > >> > > >> +static inline bool selinux_policycap_execute_sxid_no_trans(void) > > >> +{ > > >> + struct selinux_state *state = &selinux_state; > > >> + > > >> + return READ_ONCE(state->policycap[POLICYDB_CAPABILITY_EXECUTE_SXID_NO_TRANS]); > > >> +} > > >> + > > >> + > > >> struct selinux_policy_convert_data; > > >> > > >> struct selinux_load_state { > > >> -- > > >> 2.34.1 > > >> > > > > > > > > > > > > -- > > Chris PeBenito > > > > -- > paul-moore.com
On Sat, Jun 17, 2023 at 2:09 PM Christian Göttsche
<cgzones@googlemail.com> wrote:
> On Fri, 16 Jun 2023 at 07:43, Petr Lautrbach <plautrba@redhat.com> wrote:
> > Paul Moore <paul@paul-moore.com> writes:
> >
> > > Hello all,
> > >
> > > Amongst Christian's various other SELinux contributions, over the past
> > > several years Christian has been working on improving the SELinux
> > > integration in systemd. One of the things that Christian has been
> > > working on is revamping the SELinux permissions that systemd uses for
> > > unitfile operations, both to resolve problems and generally improve
> > > the mapping of permissions to systemd operations. As this work has
> > > been languishing for several years, I would like to see if we can get
> > > things "unstuck" by proposing two things:
> > >
> > > 1. I've provided links to the systemd GH PRs below, but I think it
> > > might be helpful if Christian could provide a quick summary of the new
> > > permissions, how they map to systemd operations, and how they map to
> > > the existing SELinux/systemd permissions with a focus on helping
> > > policy developers migrate existing SELinux policies.
> > >
> > > 2. Given the significance of systemd to modern Linux distributions, I
> > > think it might be a good idea if we selected a SELinux "liaison" for
> > > the systemd project. This person, or group of people, would work with
> > > the systemd folks to keep the SELinux integration in good working
> > > order, review systemd code as necessary, and help represent the
> > > SELinux project within systemd.
> > >
> > > How does that sound to everyone? If we are in agreement on #2, and
> > > assuming he would be willing to help out, I would like to nominate
> > > Christian as our SELinux liaison to systemd; any objections? Anyone
> > > else interested in helping out?
> >
> > I agree with the Christian's nomination.
> >
> > As for #1, I looked on both, but I have to admit that I had a lack of
> > understanding of the problem and so I would need some time to get
> > into it. Therefore I postponed it due to other priorities, (but never
> > come back). If it's still open I'll focus on it next week.
> >
> >
> > > For reference, Christian's systemd PRs on GH:
> > > * https://github.com/systemd/systemd/pull/10023
> > > * https://github.com/systemd/systemd/pull/20387
> > >
> >
> > Thanks,
> >
> > Petr
> >
>
> Hi all,
>
> Thanks Paul for attracting some attention to the SELinux integration
> of systemd. It has been several months since I last worked on the
> systemd related patches, so they all need a rebase and another round
> of testing.
>
> Addressing the first point, here are some details about the changes I
> would like to see in systemd ...
Thanks for all the details Christian :)
--
paul-moore.com
On Fri, Jun 16, 2023 at 1:43 AM Petr Lautrbach <plautrba@redhat.com> wrote:
> Paul Moore <paul@paul-moore.com> writes:
> > Hello all,
> >
> > Amongst Christian's various other SELinux contributions, over the past
> > several years Christian has been working on improving the SELinux
> > integration in systemd. One of the things that Christian has been
> > working on is revamping the SELinux permissions that systemd uses for
> > unitfile operations, both to resolve problems and generally improve
> > the mapping of permissions to systemd operations. As this work has
> > been languishing for several years, I would like to see if we can get
> > things "unstuck" by proposing two things:
> >
> > 1. I've provided links to the systemd GH PRs below, but I think it
> > might be helpful if Christian could provide a quick summary of the new
> > permissions, how they map to systemd operations, and how they map to
> > the existing SELinux/systemd permissions with a focus on helping
> > policy developers migrate existing SELinux policies.
> >
> > 2. Given the significance of systemd to modern Linux distributions, I
> > think it might be a good idea if we selected a SELinux "liaison" for
> > the systemd project. This person, or group of people, would work with
> > the systemd folks to keep the SELinux integration in good working
> > order, review systemd code as necessary, and help represent the
> > SELinux project within systemd.
> >
> > How does that sound to everyone? If we are in agreement on #2, and
> > assuming he would be willing to help out, I would like to nominate
> > Christian as our SELinux liaison to systemd; any objections? Anyone
> > else interested in helping out?
>
> I agree with the Christian's nomination.
>
> As for #1, I looked on both, but I have to admit that I had a lack of
> understanding of the problem and so I would need some time to get
> into it. Therefore I postponed it due to other priorities, (but never
> come back). If it's still open I'll focus on it next week.
Thanks.
--
paul-moore.com
On Fri, 16 Jun 2023 at 07:43, Petr Lautrbach <plautrba@redhat.com> wrote: > > Paul Moore <paul@paul-moore.com> writes: > > > Hello all, > > > > Amongst Christian's various other SELinux contributions, over the past > > several years Christian has been working on improving the SELinux > > integration in systemd. One of the things that Christian has been > > working on is revamping the SELinux permissions that systemd uses for > > unitfile operations, both to resolve problems and generally improve > > the mapping of permissions to systemd operations. As this work has > > been languishing for several years, I would like to see if we can get > > things "unstuck" by proposing two things: > > > > 1. I've provided links to the systemd GH PRs below, but I think it > > might be helpful if Christian could provide a quick summary of the new > > permissions, how they map to systemd operations, and how they map to > > the existing SELinux/systemd permissions with a focus on helping > > policy developers migrate existing SELinux policies. > > > > 2. Given the significance of systemd to modern Linux distributions, I > > think it might be a good idea if we selected a SELinux "liaison" for > > the systemd project. This person, or group of people, would work with > > the systemd folks to keep the SELinux integration in good working > > order, review systemd code as necessary, and help represent the > > SELinux project within systemd. > > > > How does that sound to everyone? If we are in agreement on #2, and > > assuming he would be willing to help out, I would like to nominate > > Christian as our SELinux liaison to systemd; any objections? Anyone > > else interested in helping out? > > I agree with the Christian's nomination. > > As for #1, I looked on both, but I have to admit that I had a lack of > understanding of the problem and so I would need some time to get > into it. Therefore I postponed it due to other priorities, (but never > come back). If it's still open I'll focus on it next week. > > > > For reference, Christian's systemd PRs on GH: > > * https://github.com/systemd/systemd/pull/10023 > > * https://github.com/systemd/systemd/pull/20387 > > > > Thanks, > > Petr > Hi all, Thanks Paul for attracting some attention to the SELinux integration of systemd. It has been several months since I last worked on the systemd related patches, so they all need a rebase and another round of testing. Addressing the first point, here are some details about the changes I would like to see in systemd. There are some systemd specific ones and some which also affect other object managers, e.g. D-Bus. I. Re-add SELinux checks for unit install operations systemd v190 introduced SELinux checks for unit install operations, like enabling a unit. This is useful to limit the access of daemons, which are running as root and having access to systemd via the D-Bus connection. The related security class is `service { start stop status reload enable disable }` used by both the Reference Policy and the Fedora one. Due to an internal refactoring the checks for unit install operations were dropped in systemd v225[1], so starting or stopping a unit is still subject to a SELinux check but en-/disabling or un-/masking are not. Reintroducing those checks was the initial intention for my patches. The most recent pull request targeting this issue is #20387[2] (it contains some additional changes I am going to talk about in the next section). Migration and compatibility with regard to SELinux policies depend on the individual policy. When they do not define the security class `service` or its permissions `enable` and `disable` the policy setting deny_unknown will determine whether the proposed checks are granted or denied. Both the Reference Policy and the Fedora one however do define those two permissions. For generic access they use the permission macros `manage_service_perms` and `all_system_perms ` (which include `enable` and `disable`), so the sysadm and unconfined domains should continue to work fine. Individual module interfaces, especially in the reference policy, might need some tweaks in the case a caller is actually en-/disabling a unit, as they commonly use the lone permissions `start` and/or `stop` directly. II. Introduction of two new unit permissions Even with the re-introduction of the unit install operations several other unit operations are still not subject to any SELinux check: * applying a preset to a unit (`systemctl preset <unit>`) * reverting a unit (`systemctl revert <unit>`) * modifying dependencies of a unit (`systemctl add-wants/add-requires <unit>`) All of them might influence the behavior of a unit and therefore should from a SELinux point of view not be granted by default to all root user D-Bus clients of systemd. To address them the last commit of #20387[2] introduces two new permissions to the security class `service` and `system`: `preset` and `modify`. The same commit also changes the permission for modifying systemd internal settings (via the D-Bus interface org.freedesktop.DBus.Properties) from currently `reload` to the newly added permission `modify`. This allows a more fine-grained access. During my last test run setting the log level or target was an example for such a setting modification (I'll retest after the rebase). Regarding compatibility any policy with a policy setting of `deny_unknown allow` will not break, such as the Reference Policy and the Fedora Policy. They should however consider adding and using the added permissions (mainly by adding both to the permission macro `manage_service_perms`), otherwise the previously checked setting of systemd properties will be allowed by default (for root user D-Bus clients of systemd). Confined usage of the new permissions might hopefully be quite uncommon affecting only very few domains. III. Add SELinux checks for systemd-logind D-Bus interfaces Over the years logind gained a lot of functionality[3]. Also from my experience various services talk to logind over D-Bus. So it might to be a good candidate to add some checks around the more invasive D-Bus interfaces of logind, especially everything related to reboot handling and session management (used by pam_systemd(8) clients like sshd or local_login), again to limit the default access of root user D-Bus clients. There is no actual proposal patch yet for this, only an ancient work-in-progress branch[4]. Compatibility should be trivial for policies with `deny_unknown` set to `allow` (like Reference Policy and Fedora Policy) since all potential checks will be against an entire new security class. Otherwise mainly the sysadm and unconfined domains as well as pam_systemd(8) clients need adjusting. IV. Improve audit fields on SELinux denials This topic is not specific to systemd but affects all SELinux object managers which perform access control on third party subjects, but systemd is probably the most affected one (together with D-Bus (reference implementation and dbus-broker). Today's audit messages from SELinux denials in object manager look like the following: # dbus-broker type=USER_AVC msg=audit(22/09/22 16:58:47.569:313) : pid=789 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: granted { send_msg } for scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' # systemd type=USER_AVC msg=audit(22/09/22 15:35:47.847:132) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc: granted { reload } for auid=unset uid=root gid=root cmdline="" function="method_reload" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=system exe=/usr/lib/systemd/systemd sauid=root hostname=? addr=? terminal=?' They contain the subject and target context relevant for policy rules, but are missing some information to improve understanding the cause of the denial. For example the PID, command or executable name of the actual subject is not included. Also in the case of systemd the embedded message contains a duplicated `auid` field and reuses the field names `uid` and `gid`. The kernel part of the USER_AVC messages provide the following: - pid=789 : the PID of the message issuer (not of the process subject to the failed SELinux check) - uid=dbus : UID of the message issuer - auid=unset : AUID of the message issuer - ses=unset : session ID of the message issuer - subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 : security context of the message issuer - msg='...' : the message of the issuer Libselinux (src/avc.c:avc_audit()) provides a message formatting of avc: granted { send_msg } for <<<callback-generated-content>>> scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus and libaudit (lib/audit_logging.c:audit_log_user_avc_message()) appends the following into the msg field: exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=? So I would like to introduce a recommended way for SELinux object managers to format the embedded message, supplied via the selinux_set_callback(3) option SELINUX_CB_AUDIT. They are recommended to supply the uid, gid, pid, exe and cmdline of the actual subject. Also they should supply the auid of the actual subject as the last argument of audit_log_user_avc_message(3) (and not their own), since the auid of the issuer is already supplied by the kernel. To distinguish the subject related fields they should be unique, either via a common prefix of just "s" or "subj_", inspired by the current list of audit event fields[5]. I tried to start a discussion about that in the audit issue tracker[6] and proposed two pull requests against systemd[7,8]. A more standardized and verbose USER_AVC output would benefit SELinux reporting tools like setroubleshoot[9]. Some miscellaneous notes at the end: The initial pull request of the re-addition of SELinux checks for unit install operations[10] renamed the security class for systemd manager access control (currently "system"). This was to split the userspace portion of this class from the original kernel portion. It was dropped to simplify the transition and minimize the code changes. I am not familiar with all features of systemd and might not be aware of some classes of issues. For example there exists a pull request from Daniel Walsh regarding labels of nspawn containers[11]. Regards, Christian [1]: https://github.com/systemd/systemd/pull/1044 [2]: https://github.com/systemd/systemd/pull/20387 [3]: https://www.freedesktop.org/wiki/Software/systemd/logind/ [4]: https://github.com/systemd/systemd/pull/15245 [5]: https://access.redhat.com/articles/4409591#audit-event-fields-1 [6]: https://github.com/linux-audit/audit-userspace/issues/283 [7]: https://github.com/systemd/systemd/pull/25264 [8]: https://github.com/systemd/systemd/pull/25322 [9]: https://gitlab.com/setroubleshoot/setroubleshoot/-/merge_requests/19 [10]: https://github.com/systemd/systemd/pull/10023 [11]: https://github.com/systemd/systemd/pull/26141
Paul Moore <paul@paul-moore.com> writes: > Hello all, > > Amongst Christian's various other SELinux contributions, over the past > several years Christian has been working on improving the SELinux > integration in systemd. One of the things that Christian has been > working on is revamping the SELinux permissions that systemd uses for > unitfile operations, both to resolve problems and generally improve > the mapping of permissions to systemd operations. As this work has > been languishing for several years, I would like to see if we can get > things "unstuck" by proposing two things: > > 1. I've provided links to the systemd GH PRs below, but I think it > might be helpful if Christian could provide a quick summary of the new > permissions, how they map to systemd operations, and how they map to > the existing SELinux/systemd permissions with a focus on helping > policy developers migrate existing SELinux policies. > > 2. Given the significance of systemd to modern Linux distributions, I > think it might be a good idea if we selected a SELinux "liaison" for > the systemd project. This person, or group of people, would work with > the systemd folks to keep the SELinux integration in good working > order, review systemd code as necessary, and help represent the > SELinux project within systemd. > > How does that sound to everyone? If we are in agreement on #2, and > assuming he would be willing to help out, I would like to nominate > Christian as our SELinux liaison to systemd; any objections? Anyone > else interested in helping out? I agree with the Christian's nomination. As for #1, I looked on both, but I have to admit that I had a lack of understanding of the problem and so I would need some time to get into it. Therefore I postponed it due to other priorities, (but never come back). If it's still open I'll focus on it next week. > For reference, Christian's systemd PRs on GH: > * https://github.com/systemd/systemd/pull/10023 > * https://github.com/systemd/systemd/pull/20387 > Thanks, Petr
Hello all, Amongst Christian's various other SELinux contributions, over the past several years Christian has been working on improving the SELinux integration in systemd. One of the things that Christian has been working on is revamping the SELinux permissions that systemd uses for unitfile operations, both to resolve problems and generally improve the mapping of permissions to systemd operations. As this work has been languishing for several years, I would like to see if we can get things "unstuck" by proposing two things: 1. I've provided links to the systemd GH PRs below, but I think it might be helpful if Christian could provide a quick summary of the new permissions, how they map to systemd operations, and how they map to the existing SELinux/systemd permissions with a focus on helping policy developers migrate existing SELinux policies. 2. Given the significance of systemd to modern Linux distributions, I think it might be a good idea if we selected a SELinux "liaison" for the systemd project. This person, or group of people, would work with the systemd folks to keep the SELinux integration in good working order, review systemd code as necessary, and help represent the SELinux project within systemd. How does that sound to everyone? If we are in agreement on #2, and assuming he would be willing to help out, I would like to nominate Christian as our SELinux liaison to systemd; any objections? Anyone else interested in helping out? For reference, Christian's systemd PRs on GH: * https://github.com/systemd/systemd/pull/10023 * https://github.com/systemd/systemd/pull/20387 -- paul-moore.com
-------- Forwarded Message -------- Subject: ANN: SELinux repository changes Date: Wed, 24 May 2023 16:33:43 -0400 From: Paul Moore <paul@paul-moore.com> To: selinux@vger.kernel.org Hello all, On behalf of all the various SELinux maintainers and myself, I wanted to provide a quick update on some changes that occurred today to the SELinux Project repositories hosted on GitHub. * https://github.com/SELinuxProject The first, and most noticeable change, is all of the repositories have now changed their default branch from "master" to "main". In order to minimize the immediate impact of the change, the "master" branch has been preserved and locked; this should allow existing automations to continue to function, but be warned that any new commits/PRs will be merged into "main". You can expect the "master" branches to be removed at a later date. For those of you with local repository clones, you can update your repo with the following commands: (assuming your GitHub remote is named "origin", and you are in your "master" branch) % git remote update origin % git branch -m main % git branch -u origin/main main The commands will pull in the new remote branch definition, rename your current "master" branch to "main", and set the current local "main" branch to pull from the remote "origin/main" branch. The second, and long overdue, change was to archive the CIL repository. With CIL development moving to the main SELinux userspace repository, and no new commits in over nine years, it was time to deprecate the old CIL repository. -- paul-moore.com
A new release of SETools is available: https://github.com/SELinuxProject/setools/releases/tag/4.4.2 Changes: * Make NetworkX optional. sedta and seinfoflow tools, along with the equivalent analyses in apol, require NetworkX. * Change unit test runner to pytest as setuptools' test command is deprecated. * Remove neverallow options in sesearch and apol. These are not usable since they are removed in the final binary policy. * Unit tests and CI tests improvements. -- Chris PeBenito