On Thu, January 10, 2008 05:57, Tetsuo Handa wrote:
If you want a secure system it isn't that unreasonable to expect
applications to not do brain dead things, so not requiring any
modifications or config changes seems a bit optimistic to me.
Legacy applications should cope with a static /dev/.
What is the advantage of your filesystem compared to a static /dev/?
Oh, it isn't? Which other applications do modify /dev files? I'd like to
hear about a few, no matter how obscure or proprietary. And please
tell how many of those will stop working with a static /dev with all
nodes they might create already existing.
No, why should the kernel be involved? The tiny daemon would be
the only one allowed to modify /dev/, so all mknod commands will
be done by it. Of course it means that you might need to modify
the two or three apps wanting to create device nodes, or you can
make an LD_PRELOAD lib that intercepts mknod commands and
sends them to the daemon.
The ammount of code will be the current parsing code + a few hundred
lines of code, including the preloaded library.
No, it doesn't, and most of those problems are true for all programs
that access /dev! If those are straced or whatever they can be forced
to open the wrong file, practically breaking the filename/attribute pairs.
So all security you think you need to have for the daemon process is
the same security you already need for all processes anyway to protect
them against each other.
Actually, I assumed that was the case, because if it's strictly white-list
based it's almost the same as a static /dev with some nodes hidden.
Without it has even less value, because it just complicates matters
compared to a normal static dev.
I thought it checked that if a device name was in the list, it has the
correct attributes, and was free to create nodes without restricted
names.
Yes, but as the process creates the device it can also choose the file mode and
probably also ownership. And as it creates a new file there likely aren't strict
MAC rules in place restricting the process from reading or writing to it. So
yes, you're right, but in practise it isn't as easy to close that hole,
especially
not if the applications isn't very clean and single purpose. If it creates the
node
it probably wans to use it too, and that means read/write access. Even if it can
live without it, it could give access to the node to another process and let the
other process do the dirty work. Very tricky.
Greetings,
Indan
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
