So?
The device nodes have to be deletable if some process (including udev) needs to delete.
Thus, you cannot unconditionally prevent processes from changing those files.
Yes.
If MAC system needn't to support this filesystem's functionality,
who creates those files with warrantee of expected attributes? The udev does?
If udev is exploited, who can guarantee?
Do you think all MAC implementation have the same granularity and functionalities?
I don't think so. Not all MAC implementation can control with such granularity.
This filesystem is designed to be combined with any MAC,
although the MAC used with this filesystem should be able to restrict
namespace manipulation requests so that this filesystem can remain /dev
and visible to userland applications.
If I modify udev to enforce certain filename/attribute pairs and the modified udev
was exploited, who can guarantee?
"Don't trust userland application" is the basis of restricting access in kernel space.
If you can trust userland application, you don't need in-kernel access control.
Of course. To permit the above operation, the following permissions are needed.
hda1 660 0 6 2 b 3 1
hda1 777 0 0 33 l .
Do you think all MAC implementation can prohibit renaming for certain files in /dev ?
Do you think all MAC implementation can do?
I think the first one is implementation specific and the second one is generic.
But MAC cannot prevent udev from modifying /dev . And what if exploited?
Not all MAC can enforce access control over all processes with the granularity
you are talking. And what if a process that cannot be controlled with your
boolean level granularity exists (e.g. an administrator running his/her
administrative applications that require modification of /dev )?
A crazy example of administrative applications:
(Please don't say "Don't use such crazy application".)
#! /bin/sh
rm -f /dev/either-null-or-zero
read
mknod /dev/either-null-or-zero c 1 $REPLY && echo "Administrative task finished successfully." | mail root
This filesystem can guarantee /dev/either-null-or-zero is either char-1-3 or char-1-5 by using a policy
either-null-or-zero 666 0 0 3 c 1 3
either-null-or-zero 666 0 0 35 c 1 5
The boolean level granularity (e.g. forbid all processes except for udev ,
and modify udev to perform name/attribute pair enforcement) is not generic.
Userland application sometimes misbehaves.
I assume kernel process doesn't misbehave.
If you doubt my assumption, you have to doubt in-kernel MAC implementation too.
Can SELinux guarantee the same result as my filesystem even if udev or
administrative programs have to be able to modify /dev ?
Yes.
But sometimes some modifications needs to be permitted.
Who can guarantee that there is no application (other than udev)
that creates/deletes /dev/zero instead of /dev/either-null-or-zero ?
Yes, they are the boundary.
If everyone can always get source code and modify the source code
and make the code always error-free, I don't need in-kernel implementation.
As I said, userland application sometimes misbehaves.
I trust only in-kernel access control implementations
about guaranteeing name/attributes pairs.
Thanks.
--
