On Mon, 2 May 2005, Mike Smith wrote:
>
> Speaking for the system, I don't want anything doing work as root that
> does not *need* to run as root.
>
> A firmware uploader for a device driver does not need to run as root
> if the image can be validated.
Yep.
> If it is implemented inside the driver, it must run as root. If it is
> implemented in a daemon/helper application, it can (and ideally should)
> run as someone other than root.
>
> Note that if you run the helper as, e.g. daemon/daemon, it is not
> possible
> to become that user without having been privileged at some point.
>
> This guards you against uploads by arbitrary users, but does not require
> that the uploader actually run with privilege. It's a much better
> way to
> go about it.
Excellent! That is a very workable solution that I could be happy with.
I note that in my setup, the uid of daemon is 1. Is this a good way to
check for it, just check that the uid of the calling process is 1?
> > I see a major problem with making a kext depend on anything
> > external. The
> > more complicated it is, the worse the dependency. The problem is that
> > having an external dependency _extends your trust to that dependency_.
> > Even when it is just giving you data, you have to trust that data. The
> > tracking of tainted data in perl is a concrete example of this
> > thinking.
>
> Ultimately you are trusting the filesystem; in other words, your
> protection only extends to the point that you assume that an
> attacker has never had privilege.
>
> In order to trust your uploader, you do not need for it to have
> privilege,
> merely to demonstrate that at some point it had it.
Totally agree. I didn't realise that the daemon user was available and
sanctioned for general use.
<snip more stuff that using daemon/daemon solves>
> >>> And surely the funky virtual memory and kernel threads that make up
> >>> the Darwin kernel environment alleviate some of the deadlock/design
> >>> concerns?
> >>
> >> That's a great design approach: "it's complicated, surely it must
> >> work". 8)
> >
> > My point was not that it was complicated. My point was that the kernel
> > environment is very much like the process environment.
>
> And the point I have been trying to make all along is that is *not*.
>
> I understand that you think that because you have something called
> "open"
> and a function out of <vnode_internal.h> that looks like "read" and
> "write", you have userland-like semantics.
Yes, it definitely gives that impression, especially being in the new and
supported KPI. If you say it's not the same thing, then I'll believe you.
(Although, I did follow through the system call path to see that it was
similar.) My first version used VNOP_READ before I discovered that the
utility method vn_rdwr was actually in the KPI, 'tho its prototype was
not in the installed headers.
> > vnode_open( char * name, mode, &ptr );
> > vnode_unlock( ptr );
>
> You shouldn't do this; the vnode comes to you ready to use. What led
> you to
> believe it needed to be unlocked?
I got a deadlock when reading (both with and without vn_rdwr) if I didn't
unlock it first. It could have been due to an earlier mistake 'tho...
> > vn_rdwr( READ, ptr, buf, size, offset, flags );
>
> Did you plan on closing it at some point?
Of course! Also, I go and get the size (with vnode_getattr which is
exported unlike vnode_size) before the read to make sure I'm not reading
too much. My example was only to only to show how nice reading a file
looks.
<snip more stuff that using daemon/daemon solves>
> > A startup item is not appropriate for hot pluggable drivers such those
> > for PCMCIA cards (and USB/FireWire boxes, but they don't have quite
> > the
> > same trust issues).
>
> A startup item works just fine. It starts, then waits for the device
> to show up.
> When it shows up and the driver attaches, it uploads the firmware to the
> driver.
So you do not have a problem with my daemon running all the time? I would
have thought that cluttering up the ps list was a bit of a concern. That's
a general reaction against the idea of daemons too... a whole lot of
things are coming with their own daemon now which makes uninstallation
unobvious, and reminds me of the impenetrable Windows tasklist, where you
never know what anything is for and or why it's chewing all your CPU :)
I am actually writing my own daemon anyway for userspace drivers to plug
into and to share their services automagically over Bonjour. I guess I
could integrate firmware loading into it.... hmmm.
> This involves:
>
> 1) No daemon running with privilege
> 2) No file I/O inside the kernel
> 3) No route to compromising the firmware image without having privilege
> 4) Less code within the kernel
> 5) A simple, modular design
Yes, we have a winner folks!
> = Mike
{P^/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden
