While reading AppArmor's patch, I noticed that TOMOYO's mount permission check
becomes inaccurate when multiple mount flags are passed, for userspace can pass
in arbitrary combinations of MS_* flags to mount() request. Two examples:
If both MS_BIND and one of MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE are
passed, device name which should be checked for MS_BIND was not checked
because MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE had higher priority than
MS_BIND.
If both one of MS_BIND/MS_MOVE and MS_REMOUNT are passed, device name which
should not be checked for MS_REMOUNT was checked because MS_BIND/MS_MOVE had
higher priority than MS_REMOUNT.
I fixed this bug by changing priority to MS_REMOUNT -> MS_BIND ->
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE -> MS_MOVE as with do_mount() does.
Also, I changed to unconditionally return -EINVAL if more than one of
MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE is passed so that TOMOYO will not
generate inaccurate audit logs, for commit 7a2e8a8f "VFS: Sanity check mount
flags passed to change_mnt_propagation()" clarified that these flags must be
exclusively passed.
TOMOYO 2.3 (Linux 2.6.36) and later has this bug.
Patch for TOMOYO 2.5 will be included in Linux 3.4.
Fixing this bug might require correction of policy if access control for mount
operation is enabled (though correction of policy will unlikely be required
because applications unlikely pass MS_* flags combination in a way TOMOYO hits
examples shown above).
Also, UMH_WAIT_PROC constant (currently 1) is scheduled for renumbering in
Linux 3.4. I changed to use UMH_WAIT_PROC constant instead of hardcoded
constant in case renumbering was backported.
Unfortunately, there is no means to detect this renumbering at runtime. If you
started to experience kernel panic upon execution of external policy loader
(i.e. /sbin/ccs-init) due to the kernel no longer waiting for completion of
external policy loader process, please check whether renumbering was backported
or not. (Same thing will happen to /sbin/tomoyo-init process if renumbering
patch was backported without changing TOMOYO 2.x code to use UMH_WAIT_PROC
constant. Please be careful if you are backporting TOMOYO 2.x.)
Regarding ccs-tools-1.7.3 package, I fixed two bugs and made two enhancements.
/usr/sbin/ccs-checkpolicy
Fix validation failure with number_group entries.
/usr/sbin/ccs-editpolicy
Allow optimization command ('o' key) to exception policy.
Fix wrong copy to buffer command ('insert' key) from Process State Viewer
mode.
/usr/lib/ccs/init_policy
Generate wildcarded allow_read entries.
Regarding ccs-tools-1.8.3 package, I made a small change to policy editor's
header line because Toshiharu told me that printing number of selected entries
makes it easier to confirm whether optimization command ('o' key) has selected
any lines or not.
If no line is selected, the header line looks like below.
<<< Exception Policy Editor >>> 109 entries '?' for help
If one or more lines are selected, the header line looks like below.
<<< Exception Policy Editor >>> 109 entries (9 selected) '?' for help
Please let me know if you found any problems.
ccs-patch-1.6.9-20120301.tar.gz MD5: 111184bfdcc6342987af4f431895e382
ccs-patch-1.7.3-20120301.tar.gz MD5: 1111d8fb724cae0c7b0dd8a3b294c55f
ccs-patch-1.8.3-20120301.tar.gz MD5: bbbbc6a0872028ed17d623af720a73bd
ccs-tools-1.6.9-20120301.tar.gz MD5: 9999b891210fb4d79da4e9ebefc92236
ccs-tools-1.7.3-20120301.tar.gz MD5: 777796417338fff302597456bbf9e0b7
ccs-tools-1.8.3-20120301.tar.gz MD5: dddd6ca49a2f73bef77590cd4d199a9f
akari-1.0.25-20120301.tar.gz MD5: 6666311eece23c6250957dca91083b6e
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
