<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 27, 2022 at 5:01 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/25/22 09:52, enh wrote:<br>
> On Thu, Aug 25, 2022 at 1:05 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<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>
> <br>
> yeah, from what i remember, that's roughly what the people who actually know<br>
> what they're talking about said that they'd need. but that's also what they<br>
> thought they wouldn't be able to get upstream in any realistically-spendable<br>
> amount of time.<br>
<br>
I don't suppose anyone ever roughed up a kernel patch?<br></blockquote><div><br></div><div>not that i remember or could find any evidence of. given that we'd need a userspace component anyway, and already have a working one, it was unclear that it would bring anything but disruption, new bugs, and a bunch of time spent arguing with upstream over something we didn't really _need_ anyway.</div><div><br></div><div>see also <a href="https://www.mail-archive.com/seandroid-list@tycho.nsa.gov/msg02393.html">https://www.mail-archive.com/seandroid-list@tycho.nsa.gov/msg02393.html</a> (and the rest of the thread) for thoughts from someone who probably looked into it the most. (and that thread also ends with "what's the practical benefit [of moving to devtmpfs]?" with no answer.)</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">
Rob<br>
</blockquote></div></div>