Hi Tetsuo,
I think you focus too much on your way of enforcing filename/attributes
pairs. The same can be achieved by creating the device nodes with
expected attributes, and preventing processes from changing those files.
This because expected combinations are known beforehand. And once
those files are present, the MAC system used doesn't have to have special
device nodes attributes support. Protecting those files is enough to
guarantee filename/attributes pairs.
On Tue, January 8, 2008 14:50, Tetsuo Handa wrote:
No, this is because rename permission was given for files that it shouldn't had.
Either you want a process to manage device names and attributes, and then you
give it permission to do that, or you want to enforce certain filename/attribute
pairs and then you just do it yourself.
Will your filesystem prevent the trivial case of
rm /dev/hda1
ln -s /dev/hda2 /dev/hda1
Rename permission can be given for /dev in general, but prohibited for
certain files in /dev, the ones you want to have specific attributes.
It isn't all or nothing.
It's "forbid modifying certain nodes that process needn't to modify"
versus "forbid breaking filename/attribute pairs of certain nodes".
Both have the same effect, except that the first one is generic and
can be done by existing MAC systems, while the second one needs
a special filesystem and a handful of MAC rules to make it effective.
It doesn't matter where they are, it's that a different fs than yours could be
mounted over it. You say a MAC can prevent that from happening, but a
MAC can also prevent all processes except for udev from modifying /dev.
Done globally instead of as a filesystem it can actually guarantee name/attr
pairs, now it can't even do that on its own.
I don't. What I complain about is that it's too specific and does it one chosen
job badly. It lacks abstraction. As far as I can see any decent MAC can achieve
the same end result as your filesystem, without directly enforcing name/attr
pairs.
The thing is, all special device nodes that are expected to exist by applications
are known beforehand. Thus they can be created statically and can be protected
against any modifications with any MAC system.
The dynamic nodes aren't known beforehand, so applications can't expect anything
specific. And for things like usb-sticks andwhatnot, so what if the app gets hda2
instead of the proper sdc1? It shouldn't matter, because at that point the
malicious
process has access to the device anyway, so all potential harm that could've been
caused by the confusion (if any, which I doubt) it could do itself already.
That doesn't make it better.
That's because the way you would do it in MACs is the same wrong way as
you do it now.
Call me silly, but implementing your checks in udev, or whatever handles /dev,
and disallowing everything else from modifying /dev would also have the same
effect. Or if you don't trust udevd write your own tiny replacement which does
the checking, I'm sure that can be done in little extra code. Or modify udev so
that it doesn't handle /dev directly, but passes it to your daemon who does the
ckecks you want.
Because all your filesystem does is handling the case that udev is exploited,
when a proper MAC system is used.
There are so many ways to achieve the same goal, but better, and if you're really
serious about guarantees it shouldn't be in the filesystem anyway.
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
