On Apr 30, 2005, at 8:11 AM, John Dalgliesh wrote:
On Fri, 29 Apr 2005, Mike Smith wrote:
On Apr 11, 2005, at 11:11 PM, John Dalgliesh wrote:
I'm sorry, I don't understand the differences in permission/trust
between
a daemon running as root, and a thread running in the kernel. I had
assumed that they were equivalent. And if your daemon is not
running as
root (or similar) then how can you trust what it has written out if
you
ever need to read it back in?
How can you trust it anyway?
You can trust the daemon when it is root, because root can do
anything.
That's not trust, but it highlights exactly what's *wrong* with
running as root.
If you have a daemon helper for your kext, it doesn't have to run as
root.
That way, the system does not have to trust it. Instead, it's forced
to trust
your kext even though it does not want to.
Besides, the argument of not trusting any userspace daemon to
handle data
that kexts depend on... is sensible sure, but not convincing to
keep file
access out of the kernel :)
You've got the whole thing backwards; see above.
With regards to differences in privilege, authorisation is
enforced at the
boundaries into the kernel; code inside the kernel is generally
assumed
to have vetted the source of requests before passing them to the
lower
layers.
Yes, and a lot of that code goes "if (!root) return EPERM;" or
equivalent.
Right again. Because a degree of trust is implicit in running as root,
and the system only wants things that are trusted running as root.
From a quick look, the NVRAM property setter appears to be a good
example.
If you're not root, you can only set a few well-known user-settable
properties. If you are root, you can set any property. The kernel
has no
way of knowing what affect setting it to the given data will have - it
trusts calls from root to give it data that isn't bogus. And the type
checking that it does perform is equally available to kernel
callers as
it is to userspace callers.
Right again. Unless the system trusts you to become root, you can't
do much in the way of silly things.
Again, this is why as much code as possible should run untrusted, and
why you should do your file I/O in a daemon that is *not* running as
root.
There are many good reasons not to instigate file I/O inside the
kernel; some
more are:
- There's rarely a need for it. The basic principle; when in doubt,
leave it out.
- Deadlock opportunities abound.
- The I/O subsystem is not *designed* to handle I/O requests from
inside
the kernel.
Those are all good reasons. I totally agree that as a general rule you
don't want to do file I/O - or anything else for that matter -
inside the
kernel. But when there is an interaction between userspace and the
kernel
you have to be able to validate that interaction. The security
issues of
relying on a process external to the kernel are far worse than
those of
relying on a regular file external to the kernel, not to mention the
general badness of an increase in complexity.
On the contrary. The process is subject to all the normal rules
regarding
file access, as well as having all the benefits that are conferred on a
piece of code playing by the rules.
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)
What about the pager and all the other places that do in-kernel IO?
The pager has a user-space application (dynamic_pager) specifically
so that it can create the files it uses for paging.
There are several pieces of code inside the kernel that know how to go
about creating files safely. Those pieces of code export APIs that
allow
other pieces of code to create files; those APIs are called "system
calls".
- It's rare that you really need to read/write as root, and it is
hard to get
correct permissions enforcement for an externally-instigated
operation
if you're requesting it inside the kernel.
That one is a bit of a worry, and comes back to the trust issue.
Even if I
was to make a daemon running outside the kernel, then running it as
root
would be frowned upon? I really _really_ don't want any old user to be
able to send me the firmware that runs on my PCI card.
So validate the firmware. There's nothing preventing "any old user"
from
switching the firmware file out from under your firmware loader, and no
amount of running it as root will save you there.
