Here is the long answer.

Bhargava Shastry wrote:
> 1. There is a small change in the file *tomoyo/common.c *[- indicates
> removal of line that follows;+ indicates addition of line that follows]
> -    if (strcmp(filename, "/sbin/init") &&
> -        strcmp(filename, "/sbin/tomoyo-start")){
> +   if (strcmp(filename, "/sbin/adbd"))

As of TOMOYO 2.3, these pathnames are hardcoded into the C file. Therefore,
you need to manually edit to change to /init . This pathname will become a
kernel config option and kernel boot command line option in TOMOYO 2.4 (as with
TOMOYO 1.8.2).

> I presumed that the policy files were not accessible at the time of /init
> call

Right. /init sets up /system/ and /data/ partitions. Therefore, files accessed
by /sbin/tomoyo-init needs to be in / partition which is an initramfs.
/system/bin/linker is the binary loader for Android environment. This pathname
is hardcoded into the binary program (e.g. /sbin/tomoyo-init ).
General binary programs that are executed after /system/ partition is mounted
refer /system/lib/libc.so and /system/lib/libm.so whereas /sbin/tomoyo-init
refers /lib/libc.so and /lib/libm.so . This is done by using environment
variable LD_LIBRARY_PATH. But /sbin/tomoyo-init is executed by the kernel and
therefore LD_LIBRARY_PATH is not set. Passing LD_LIBRARY_PATH from the kernel
when executing /sbin/tomoyo-init will not save you from including libc.so and
libm.so into / partition because /system/ partition is not available when /init
is about to start.

> and thus delayed the call of policy loader to a time when the /system
> partition is mounted on Android; /sbin/adbd seems to be a call which achieves
> this goal.

That is too late to start.

> 2. The location of policy files has been moved to /usr/tomoyo from
> /etc/tomoyo
> The reason follows: /usr is a directory I have created in the rootfs and is
> part of the boot image loaded onto the phone.

Right.

> On the other hand, /etc is a sym link to /system/etc which in turn is part of
> the system image. Since I am working at the kernel level, I thought it
> appropriate to not modify the system image.

Right.

> Moreover, I feel that moving tomoyo policy files to a
> different location is a mere cosmetic change. Of course, this change entails
> a change in the directory location pointed to in tomoyo_init_policy.c which
> has been done. Would you agree?

TOMOYO 1.8.1 introduced built-in policy support which allows you to load policy
and activate access control before /init starts, without using /sbin/ccs-init
/system/bin/linker /lib/libc.so /lib/libm.so and some policy directory which is
in / partition. This feature will be included in TOMOYO 2.4.

There is an Android phone named IS01. It is using DECKARD LSM module.
According to http://www.gcd.org/blog/2010/12/682/ (sorry, that page is written
in Japanese), the protection by DECKARD was disabled by an owner of the phone
who wanted to disable it because there was a race window that allows letting
rild daemon load arbitrary kernel module before loading kernel module becomes
forbidden by writing 1 to /proc/sys/kernel/modules_disabled interface.

If policy was embedded into the kernel and enforcing mode has started before
/init is executed, it will help reducing the possibility of hijacking the boot
procedure.

Until TOMOYO 2.4 is accepted for mainline, TOMOYO 1.8 will be a lot easier to
use on Android.

_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en

Reply via email to