<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 25, 2022 at 1:05 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/24/22 10:31, enh wrote:<br>
> On Wed, Aug 24, 2022 at 1:13 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
>     Applied the patch, but WOW this is conceptually ugly...<br>
> <br>
>     On 8/23/22 10:57, Yi-yo Chiang via Toybox wrote:> Android doesn't use devtmpfs.<br>
> <br>
>     Huh, I thought Android was using it because you guys got blamed for shoehorning<br>
>     userspace policy into the kernel back in 2013:<br>
> <br>
>     <a href="https://lwn.net/Articles/548477/#:~:text=devtmpfs" rel="noreferrer" target="_blank">https://lwn.net/Articles/548477/#:~:text=devtmpfs</a><br>
> <br>
>     (The kernel having infrastructure to know that gid 44 is "video" and needing an<br>
>     /etc/groups that matches is kinda creepy. Yet another thing Kay Sievers<br>
>     advocated and Greg KH endorsed before Linus threw Kay out of kernel development<br>
>     and he went off to do systemd full time...)<br>
> <br>
>     Do you think Android is likely to start using devtmpfs at some point in the<br>
>     future? <br>
> <br>
> TL;DR: no, i don't.<br>
>  <br>
> although i don't directly work on that stuff (and dvander is more likely to have<br>
> a canonical answer), i know a lot of people have _hoped_ to use it and looked at<br>
> it over the years, but i don't think it's fit for purpose? the problem<br>
> (ironically, given your complaint) is that it doesn't know _enough_ about the<br>
> system. so it's racy and init has to run around after it fixing up the stuff<br>
> (like selinux labels) that it _doesn't_ set. (iirc it didn't even do regular<br>
> unix permissions right?) so if init's got to do _some_ of the work, init may as<br>
> well do _all_ of the work so there's no window where you can see a<br>
> "half-finished" node.<br>
<br>
Hence the 2013 article about putting policy into the kernel. In a terrible<br>
terrible way, brought to you by the systemd developers.<br>
<br>
What would have made SENSE was having the netlink hotplug interface (ala<br>
nlmsg_type = RTM_GETLINK) register to say it's going to send back response<br>
packets with credential info for each new node (something vaguely like<br>
nlmsghdr.nlmsg_flags = BLAH|NLM_F_SETCRED;) then having device node creation<br>
wait for the userspace credential request the same way it waits for a userspace<br>
firmware load request. You could even watchdog it where a timeout causes the<br>
device creation to return error and not make the node, and if the netlink<br>
program exits without properly deregistering (and a new instance doesn't<br>
restart) then that's gonna time out, meaning you can't do a security attack by<br>
trying to kill the daemon. (DOS sure, but show me a daemon kill that doesn't<br>
deny service.) And if you fire up the netlink daemon before mounting devtmpfs<br>
for the first time, it gets to annotate all the initial device node creations in<br>
a cleanish way so they're never exposed without credentials.<br></blockquote><div><br></div><div>yeah, from what i remember, that's roughly what the people who actually know what they're talking about said that they'd need. but that's also what they thought they wouldn't be able to get upstream in any realistically-spendable amount of time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(Making that work with different devtmpfs instances in different container<br>
levels calls for a whiteboard and multiple colors of markers, but probably isn't<br>
more than a two energy drink problem. The real questions there are all policy,<br>
not mechanism, and mostly boil down to me not having a CLUE how selinux<br>
interacts with namespaces. I assume the parent context is _providing_ the child<br>
context's hotplug events...? Do selinux rules nest? I'm pretty happy to not go<br>
there on a first pass..)<br>
<br>
Rob<br>
</blockquote></div></div>