Hello.
TOMOYO 2.x wants to use /proc/self/ rather than /proc/$PID/ if $PID matches
current thread's process ID in order to prevent current thread from accessing
other process's information unless needed. But since procfs can be mounted on
various locations (e.g. /proc/ /proc2/ /p/ /tmp/foo/100/p/ ), TOMOYO 2.x cannot
tell that whether the numeric part in the string returned by __d_path()
represents process ID or not.
Therefore, to be able to convert from $PID to self no matter where procfs is
mounted, I'm considering to change pathname representations for filesystems
which do not support rename() operation (e.g. proc, sysfs, securityfs).
Current pathname representation Proposed pathname representation
/dev/pts/0 => devpts:/0
/proc/tty/driver/serial => proc:/tty/driver/serial
/sys/kernel/security/tomoyo/domain_policy => securityfs:/tomoyo/domain_policy
/sys/power/state => sysfs:/power/state
Pathnames on filesystems which support rename() operation (e.g. ext3, tmpfs)
remain unchanged.
Advantages of this change are:
(1) You will be able to allow current thread to access only current process's
information by specifying like proc:/self/status and allow current thread
to access other process's information by specifying like proc:/\$/status .
Although it is less fine grained distinction than SELinux, it can achieve
same granularity as TOMOYO 1.x can.
(2) You will be able to allow current thread to access only specific files.
It is more fine grained distinction than SELinux because you can specify
files on procfs for per a file basis (whereas SELinux assigns proc_t for
various files on procfs).
(3) You will be able to allow accessing procfs no matter where procfs is
mounted, for all /proc/ /proc2/ /p/ /tmp/foo/100/p/ are mapped to proc:/ .
One thing I worry is that somebody is using a filesystem which can store
programs (i.e. files which can be passed to execve() requests) but cannot
support rename(). On such filesystems, TOMOYO cannot create domains because
pathnames in a domainname must start with / .
Though I think there is no such filesystem...
If you want to test this change,
you can apply patch at http://marc.info/?l=linux-fsdevel&m=127884477806888&w=2
on a snapshot at
http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=snapshot;h=4a8ece22b1e2309a76b8af0787b636dee5e85209;sf=tgz
(for TOMOYO 2.x) or
patches at
http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-patch/?root=tomoyo +
http://sourceforge.jp/projects/tomoyo/svn/view/trunk/1.7.x/ccs-patch/patches/?root=tomoyo
and
tools at
http://sourceforge.jp/projects/tomoyo/svn/view/branches/ccs-tools/?root=tomoyo
(for TOMOYO 1.x) .
Questions or opinions?
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
