Hello.
Chris Harris wrote:
> is it insecure to allow a domain to 'file read' all files
> in /usr/lib and /usr/share and subdirectories? or even all files in
> /usr and subdirectories? what i thought is that even if a domain can
> read a file in /usr/, it is no use if it cannot be
> executed/written/deleted by that domain so there is no risk.
Strictly speaking, TOMOYO does not check execute permission of a file when the
file is interpreted as a program. For example, TOMOYO checks read permission of
a shared library file rather than execute permission of the shared library file.
But I think it is acceptable to allow reading all files under /usr/ because
data which should not be read by anonymous will not be stored in /usr/ .
Thus, I think adding
acl_group 0 file read /usr/\* path1.type=file path1.perm=others_read
acl_group 0 file read /usr/\{\*\}/\* path1.type=file path1.perm=others_read
(which means allow reading regular files under /usr/ directory if the file's
DAC permission allows everybody to read) to exception policy will be OK.
> also, for some programs there are large number of 'file ioctl',
> especially for sound and video related things. is there a way to allow
> all ioctl numbers for a specific file. i tried 'file ioctl /dev/snd/\*
> \*' but it doesn't work. it is kind of a lot of work to manage many
> ioctl numbers. even if this is possible, is it a risk to do so?
The \* wildcard is used for string match. Please use numeric expression like
file ioctl /path/to/file 0-0xFFFFFFFF (for 32bit machine)
file ioctl /path/to/file 0-0xFFFFFFFFFFFFFFFF (for 64bit machine)
. You can optionally use device file's attributes like
file ioctl /\* 0-0xFFFFFFFF path1.type=char path1.dev_major=1
path1.dev_minor=3
file ioctl /\{\*\}/\* 0-0xFFFFFFFF path1.type=char path1.dev_major=1
path1.dev_minor=3
which means allow any ioctl on character device files with major = 1 and
minor = 3 (a.k.a. /dev/null).
> and final question. is it a problem to disable protection for 'misc
> env'? i am the only user to use my desktop and i am behind a router,
> so i'm not afraid of remote attackers changing LD_PRELOAD and others.
> still risky?
For your case, it is OK to disable 'misc env' checks.
I recommend granting 'misc env' permissions using acl_group. You can add
acl_group 0 misc env PATH
acl_group 0 misc env HOME
acl_group 0 misc env USER
acl_group 0 misc env SHELL
acl_group 0 misc env TERM
acl_group 0 misc env HOSTNAME
acl_group 0 misc env PWD
acl_group 0 misc env _
etc. as well as
acl_group 0 file read /lib/ld-2.5.so
to exception policy.
Environment variables like LD_\* (if needed) should be added to domain policy
rather than exception policy because globally allowing such variables is
dangerous.
Regards.
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
