Bug 2041506

Summary: Remove the SELinux lockdown class from osbuild-selinux
Product: Red Hat Enterprise Linux 9 Reporter: Zdenek Pytela <zpytela>
Component: osbuildAssignee: Image Builder team <osbuilders>
Status: CLOSED NEXTRELEASE QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: unspecified    
Version: 9.0CC: ahalaney, akoutsou, ckellner, debarshir, elpereir, obudai
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-03-02 09:46:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Zdenek Pytela 2022-01-17 14:33:44 UTC
Description of problem:
As a result of https://bugzilla.redhat.com/show_bug.cgi?id=1945581, the support for the lockdown class was also removed from selinux-policy. Please remove all references to the lockdown class in osbuild-selinux, too.

Version-Release number of selected component (if applicable):
selinux-policy-34.1.22-1.el9.noarch
osbuild-45-1.el9.noarch

How reproducible:
always

Steps to Reproduce:
1. dnf update osbuild selinux-policy

Actual results:
Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/200/osbuild/cil:89
Failed to resolve AST
/usr/sbin/semodule:  Failed!

Expected results:
no error

Additional info:

Comment 1 Christian Kellner 2022-01-18 17:21:33 UTC
I wonder if all that is needed is a rebuild of osbuild-selinux, since I dont think we use any "lockdown" class directly ourselves. Upstream code is here: https://github.com/osbuild/osbuild/tree/main/selinux

Comment 2 Zdenek Pytela 2022-01-18 17:42:58 UTC
(In reply to Christian Kellner from comment #1)
> I wonder if all that is needed is a rebuild of osbuild-selinux, since I dont
> think we use any "lockdown" class directly ourselves. Upstream code is here:
> https://github.com/osbuild/osbuild/tree/main/selinux

I've checked the content and it seems very likely that you are right and a line like this:

 29 unconfined_domain(osbuild_t)

using the previous selinux-policy package version is the source of the problems, so just a rebuild with selinux-policy-34.1.21-1.el9 or newer should resolve them.

Comment 3 Ondřej Budai 2022-03-01 14:29:02 UTC
Hi Zdeněk,

we did multiple rebuilds since this bug was created. Can you please check that the latest build of osbuild-selinux indeed doesn't contain the class? If that's true, I think we can close this issue. Thanks!

Comment 4 Zdenek Pytela 2022-03-01 15:38:25 UTC
(In reply to Ondřej Budai from comment #3)
> Hi Zdeněk,
> 
> we did multiple rebuilds since this bug was created. Can you please check
> that the latest build of osbuild-selinux indeed doesn't contain the class?
> If that's true, I think we can close this issue. Thanks!
Ondro,

Which version is the latest one or when can I check it? You can also try these commands:

# ls -ld /sys/fs/selinux/class /sys/fs/selinux/class/lockdown
dr-xr-xr-x. 136 root root 0 Feb 28 09:02 /sys/fs/selinux/class
dr-xr-xr-x.   3 root root 0 Feb 28 09:02 /sys/fs/selinux/class/lockdown

There should be only the first line, but I am not sure if the fs is mounted at all.

Comment 6 Zdenek Pytela 2022-03-02 09:32:18 UTC
Everything looks correct: package installs without erring, module is enabled, types provided:

rhel9# rpm -qa selinux-policy "*osbuild*"
selinux-policy-34.1.27-1.el9.noarch
python3-osbuild-50-1.el9.noarch
osbuild-selinux-50-1.el9.noarch
osbuild-50-1.el9.noarch

rhel9# ls -ld /sys/fs/selinux/class /sys/fs/selinux/class/lockdown
ls: cannot access '/sys/fs/selinux/class/lockdown': No such file or directory
dr-xr-xr-x. 135 root root 0 Mar  2 04:29 /sys/fs/selinux/class

rhel9# semodule -lfull |grep osbuild
200 osbuild           pp
rhel9# seinfo -xt osbuild_t

Types: 1
   type osbuild_t, application_domain_type, can_read_shadow_passwords, can_write_shadow_passwords, can_relabelto_shadow_passwords, can_change_object_identity, can_load_kernmodule, can_load_policy, can_setbool, can_setenforce, can_setsecparam, corenet_unconfined_type, corenet_unlabeled_type, devices_unconfined_type, domain, files_unconfined_type, filesystem_unconfined_type, kern_unconfined, named_filetrans_domain, process_uncond_exempt, selinux_unconfined_type, storage_unconfined_type, unconfined_domain_type, dbusd_unconfined, sepgsql_unconfined_type, can_relabelto_binary_policy, userdom_filetrans_type, x_domain, xserver_unconfined_type;

From selinux-policy pov this bz is resolved.

Comment 7 Ondřej Budai 2022-03-02 09:46:02 UTC
Thanks a lot, Zdeňku! Closing this bug.