On Thu, January 10, 2008 05:57, Tetsuo Handa wrote: > It seems to me that the alternatives you are proposing include > modification of userland applications. But my assumption is > that "Don't require modification of userland applications". 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. > In other words, I want to implement without asking applications > to use /dev/dynamic/ or something. > This filesystem is intended to provide support for legacy applications. > (In fact, this filesystem in TOMOYO Linux is for kernel 2.4.30/2.6.11 and > later.) Legacy applications should cope with a static /dev/. What is the advantage of your filesystem compared to a static /dev/? > Use of a tiny daemon that communicates with udev is not sufficient. > The udev is not the only application that modifies /dev files. 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. > At least, the tiny daemon should communicate with the kernel > so that all requests are checked by the tiny daemon. 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. > But use of the tiny daemon (which is a process running in userland) > causes a lot of troubles. 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. >> If an administrator wants something else than >> 3 or 5, you're breaking something. > That's the fate of white-list based access control. > > Does this filesystem sound too strict to support dynamic device? > May be this filesystem should be able to permit creation of device > nodes that are not listed in the policy file. 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. > From your next posting: >> But I think doing more is getting ridiculous, because if a process can >> create a device node, it can also access it and do whatever harm could >> be done by the confusion caused by unexpected name/attribute pairs. > > FYI. Being able to create a device node is different from being able to access > it and do whatever harm. You will need read and/or write permission to open > that device. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
