dmesg: allow dmesg_t access to init script stream sockets

[sasikuma-qti]

No description provided.

[thesamesam]

What socket exactly is it accessing, and what configuration do you need for it to do that? I haven't observed this and I'm curious as to what it is (this kind of information is very useful when debugging things way down the line too).

[GargiQcom]

Command executed from adb shell: adb shell dmesg

Following denials are seen:

`type=AVC msg=audit(1773565011.851:411): avc: denied { ioctl } for pid=4782 comm="dmesg" path="socket:[764973]" dev="sockfs" ino=764973 ioctlcmd=0x542a scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket permissive=1

type=AVC msg=audit(1773565011.851:412): avc: denied { getattr } for pid=4782 comm="dmesg" path="socket:[764973]" dev="sockfs" ino=764973 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket permissive=1

type=AVC msg=audit(1773565011.851:410): avc: denied { read write } for pid=4782 comm="dmesg" path="socket:[764973]" dev="sockfs" ino=764973 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket permissive=1

type=AVC msg=audit(1773565011.851:411): avc: denied { ioctl } for pid=4782 comm="dmesg" path="socket:[764973]" dev="sockfs" ino=764973 ioctlcmd=0x542a scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket permissive=1`

[thesamesam]

That makes much more sense, thank you! Please include that in the commit message.

[sasikuma-qti]

That makes much more sense, thank you! Please include that in the commit message.

Updated commit message with the denials.

[thesamesam]

Please also include that it was adb shell dmesg too. it's very puzzling otherwise.

[sasikuma-qti]

Please also include that it was adb shell dmesg too. it's very puzzling otherwise.

Updated the commit message.

[sasikuma-qti]

@pebenito / @yizhao1 to review further.

[sasikuma-qti]

@pebenito / @yizhao1 - Gentle reminder. Can you please review this change at the earliest.

[thesamesam]

It was a long weekend in the US and UK and it's only been 2 days since your last ping. I'd personally find that excessive on the projects I'm a reviewer for.

[WavyEbuilder]

As per my comments on the pipewire patch, I don't think this is correct. adb shell is clearly interactive, but for some reason is initrc_t? Which doesn't make sense. I would rather prefer that we add a domain for adb_shell_t and wire that up properly and run in a login domain than doing this, which comes off as a bit of a hack to me. I suspect that this will extent over to various policy modules too, which is not desirable as the ability to talk to unconfined, highly privileged initrc_t processes opens up quite a bit of attack surface.

[sasikuma-qti]

As per my comments on the pipewire patch, I don't think this is correct. adb shell is clearly interactive, but for some reason is initrc_t? Which doesn't make sense. I would rather prefer that we add a domain for adb_shell_t and wire that up properly and run in a login domain than doing this, which comes off as a bit of a hack to me. I suspect that this will extent over to various policy modules too, which is not desirable as the ability to talk to unconfined, highly privileged initrc_t processes opens up quite a bit of attack surface.

Yes, it will extend to many other policy modules which i am not sure on how to get this validated and reduce the ripple effort of creating a new domain for adb.