Why do you use a --label=type:unconfined_t with --privileged?

[rhatdan]

In:

https://github.com/containers/bootc#using-bootc-install

$ podman run --privileged --pid=host --net=none --security-opt label=type:unconfined_t ghcr.io/cgwalters/c9s-oscore bootc install --target-no-signature-verification /path/to/disk

--privileged would force spc_t which is unconfined and should be able to do the boot install.

Secondarily are you saying all bootc images will have an embeded bootc?

[cgwalters]

--privileged would force spc_t which is unconfined and should be able to do the boot install.

spc_t doesn't have mac_admin which allows writing unknown selinux labels. We have install_t today. If you recall this distinction has been a huge ongoing source of trouble.

• run as install_t #24
• https://bugzilla.redhat.com/show_bug.cgi?id=1937404
• build-sys: Symlink, not hard link ostree-container coreos/rpm-ostree#3323

And more.

Today I landed code such that bootc goes to quite some effort to re-exec itself as install_t. See

bootc/lib/src/lsm.rs

Line 43 in 53cd1e6

// OK now, we always copy our binary to a tempfile, set its security context

(We also need to mount selinuxfs in the container, and re-exec ourself for that)

Secondarily are you saying all bootc images will have an embeded bootc?

Yes, so they can perform in-place OS updates after install via bootc update. If you don't care about in-place transactional updates (e.g. you're doing a diskless/stateless setup via PXE or whatever) then inherently you don't really need bootc today.

This said...running the install as a privileged container but OS updates directly on the host does argue for potentially also running OS updates as a privileged container too. But my hesitation in going down this route is that it is more likely to create chicken/egg problems where your container runtime is broken, and it'd be fixed by an OS update, but to apply that OS update you need a container runtime...