Support systemd v246

[selinuxproject]

Support systemd v246

[egtvedt]

I am stuck with the same issue, currently considering a workaround by reverting systemd commit systemd/systemd@63e2d17

I do not feel switching udevadm to udev_exec_t is the correct approach.

Hans-Christian Egtvedt <[email protected]> writes:

I am stuck with the same issue, currently considering a workaround by reverting systemd commit ***@***.*** I do not feel switching udevadm to udev_exec_t is the correct approach.

Why do you think that? You might have to move some rules over and add in/remove some compatibility rules, but essentially it should be the same code. That is why they decided to merge it. it was just duplicate code occupying space. You can add a typealias for compatibility. This is (at least some of it) what i did in my personal policy to address this consolidation: https://git.defensec.nl/?p=dssp3.git;a=commitdiff;h=848385ed4a145ac2967ab9a7f1d0715ebe741fd1

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- gpg --locate-keys [email protected] Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift

Dominick Grift <[email protected]> writes:

Hans-Christian Egtvedt ***@***.***> writes: > I am stuck with the same issue, currently considering a workaround by reverting systemd commit ***@***.*** > > I do not feel switching udevadm to udev_exec_t is the correct approach. Why do you think that? You might have to move some rules over and add in/remove some compatibility rules, but essentially it should be the same code. That is why they decided to merge it. it was just duplicate code occupying space. You can add a typealias for compatibility. This is (at least some of it) what i did in my personal policy to address this consolidation: https://git.defensec.nl/?p=dssp3.git;a=commitdiff;h=848385ed4a145ac2967ab9a7f1d0715ebe741fd1

and this: https://git.defensec.nl/?p=dssp3.git;a=commitdiff;h=533ffc74b2898183c9143f7faf16d86261906d7a

…

> > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or unsubscribe. >

-- gpg --locate-keys [email protected] Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift

[pebenito]

To me, it seems that we should change udevadm to udev_exec_t and then change the old udevadm transitions to be over udev_exec_t assuming there isn't a type transition conflict.

[egtvedt]

Hans-Christian Egtvedt [email protected] writes:
I am stuck with the same issue, currently considering a workaround by reverting systemd commit @.*** I do not feel switching udevadm to udev_exec_t is the correct approach.
Why do you think that? You might have to move some rules over and add in/remove some compatibility rules, but essentially it should be the same code. That is why they decided to merge it. it was just duplicate code occupying space. You can add a typealias for compatibility. This is (at least some of it) what i did in my personal policy to address this consolidation: https://git.defensec.nl/?p=dssp3.git;a=commitdiff;h=848385ed4a145ac2967ab9a7f1d0715ebe741fd1
…
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
-- gpg --locate-keys [email protected] Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift

Ack, I was mostly concerned about two quite different programs now being merged into one type, but I guess they will have the same needs with regards to access for things to work.

[egtvedt]

I tuned my local policy file context to do
/usr/bin/udevadm -- gen_context(system_u:object_r:udev_exec_t)

And I also had to add the following policy
allow udev_t var_run_t:file { getattr open read };

And AFAICT things work as they should again, I see no violations and run in enforcing mode.

The need for udev_t to access var_run_t:file types are due to my embedded target being a bit exotic, I think that can be ignored.

[minimaxwell]

I tuned my local policy file context to do
/usr/bin/udevadm -- gen_context(system_u:object_r:udev_exec_t)

And I also had to add the following policy
allow udev_t var_run_t:file { getattr open read };

And AFAICT things work as they should again, I see no violations and run in enforcing mode.

The need for udev_t to access var_run_t:file types are due to my embedded target being a bit exotic, I think that can be ignored.

I've been testing that fix locally for a while now, and it also fixes the issue. Should we send that fix as a PR ?

Thanks,

Maxime

[pebenito]

There is also a patch on the mail list that is aimed a resolving this, but it doesn't have the var_run_t rule. That sounds like a mislabeled file.

[DemiMarie]

Another approach is to use SELinuxContext= in systemd-udevd.service.