[tomoyo-users-en 546] Problem with policy

[Paolo Bolzoni]

Dear list,
I am using linux 3.8.4, tomoyo tools 2.5.0, and I want to sandbox
the skype process.

I installed tomoyo, added the kernel line and followed the instructions
from the Archlinux wiki(0), the wiki presents a domain_policy.conf
file and a exeption_policy.conf . The two files seems reasonable to
me, and seems a good starting point to eventually fine tune.
(0) https://wiki.archlinux.org/index.php/Skype#TOMOYO

Unfortunately with those settings Skype does not start at all, and
I cannot understand the reason. I started tomoyo-auditd, and checked
the /var/log/tomoyo/reject_003.log to understand what is wrong.

I copied a part of the reject_003.log in the bottom of the email,
the first line it is expected as the original configuration file
did not mention infinality, and I fixed it with two new lines in
domain_policy.conf:

file read /etc/fonts/infinality/styles.conf.avail/infinality/\*.conf
file read /etc/fonts/infinality/\*.conf

Updating the configuration and restarting skype the lines disappear.


But the next lines completely puzzled me, the path_group in
exception_policy.conf contains all the files and directory under
~/.Skype and the configuration file domain_policy.conf the lines

file create @SKYPE_FILES 0666
file read/write/unlink/truncate @SKYPE_FILES

should ensure that Skype can do whatever it needs in the directory.
Why tomoyo is stopping the request?

Thanks for any insight,
Paolo


#2013/03/26 15:33:04# profile=3 mode=enforcing granted=no
(global-pid=12304) task={ pid=12304 ppid=8058 uid=1000 gid=1000
euid=1000 egid=1000 suid=1000 sgid=1000 fsuid=1000 fsgid=1000 }
path1={ uid=0 gid=0 ino=192620 major=0 minor=17 perm=0644 type=file }
path1.parent={ uid=0 gid=0 ino=192609 perm=0755 }
<kernel> /usr/lib32/skype/skype
file read /etc/fonts/infinality/styles.conf.avail/infinality/52-infinality.conf

#2013/03/26 15:33:04# profile=3 mode=enforcing granted=no
(global-pid=12314) task={ pid=12304 ppid=8058 uid=1000 gid=1000
euid=1000 egid=1000 suid=1000 sgid=1000 fsuid=1000 fsgid=1000 }
path1.parent={ uid=1000 gid=1000 ino=53455 perm=0700 }
<kernel> /usr/lib32/skype/skype
file create /home/paolo/.Skype/shared_dynco/dc.lock 0600

#2013/03/26 15:33:04# profile=3 mode=enforcing granted=no
(global-pid=12314) task={ pid=12304 ppid=8058 uid=1000 gid=1000
euid=1000 egid=1000 suid=1000 sgid=1000 fsuid=1000 fsgid=1000 }
path1.parent={ uid=1000 gid=1000 ino=53455 perm=0700 }
<kernel> /usr/lib32/skype/skype
file create /home/paolo/.Skype/shared_dynco/dc.lock 0600

[...]

#2013/03/26 15:33:05# profile=3 mode=enforcing granted=no
(global-pid=12314) task={ pid=12304 ppid=8058 uid=1000 gid=1000
euid=1000 egid=1000 suid=1000 sgid=1000 fsuid=1000 fsgid=1000 }
path1.parent={ uid=1000 gid=1000 ino=53475 perm=0700 }
<kernel> /usr/lib32/skype/skype
file create /home/paolo/.Skype/paolo_bolzoni/config.tmp 0600

#2013/03/26 15:33:05# profile=3 mode=enforcing granted=no
(global-pid=12318) task={ pid=12304 ppid=8058 uid=1000 gid=1000
euid=1000 egid=1000 suid=1000 sgid=1000 fsuid=1000 fsgid=1000 }
path1={ uid=0 gid=0 ino=93211 major=0 minor=17 perm=0755 type=file }
path1.parent={ uid=0 gid=0 ino=93206 perm=0755 }
<kernel> /usr/lib32/skype/skype
file read /usr/lib32/libv4l/plugins/libv4l-mplane.so

[...]

[Tetsuo Handa]

Oops, I didn't notice this mail until now.

Post by Paolo Bolzoni
I copied a part of the reject_003.log in the bottom of the email,
the first line it is expected as the original configuration file
did not mention infinality, and I fixed it with two new lines in
file read /etc/fonts/infinality/styles.conf.avail/infinality/\*.conf
file read /etc/fonts/infinality/\*.conf
Updating the configuration and restarting skype the lines disappear.

Did you run

tomoyo-loadpolicy -d < /etc/tomoyo/domain_policy.conf

after adding

file read /etc/fonts/infinality/styles.conf.avail/infinality/\*.conf
file read /etc/fonts/infinality/\*.conf

to /etc/tomoyo/domain_policy.conf ?

If you run tomoyo-savepolicy without running

tomoyo-loadpolicy -d < /etc/tomoyo/domain_policy.conf

after updating /etc/tomoyo/domain_policy.conf , changes you have made on the
/etc/tomoyo/domain_policy.conf will be lost.

Post by Paolo Bolzoni
But the next lines completely puzzled me, the path_group in
exception_policy.conf contains all the files and directory under
~/.Skype and the configuration file domain_policy.conf the lines
should ensure that Skype can do whatever it needs in the directory.
Why tomoyo is stopping the request?

This would be probably because either

/etc/tomoyo/domain_policy.conf is not loaded after it was modified

or

the domain the process is referring does not match the domain the domain
policy says (TOMOYO's domain has an inode's lifecycle semantics. A domain can
be deleted and recreated with the same name without restarting the process
referring the deleted domain. When such delete/recreate is done, the domain
the process is referring does not match the domain the domain policy says.)

To solve the former case, be sure to run tomoyo-loadpolicy if you added to
/etc/tomoyo/domain_policy.conf rather than editing directly via
tomoyo-editpolicy .

To solve the latter case, you can check the policy for currently running
processes using tomoyo-editplicy . Please see
http://tomoyo.sourceforge.jp/2.5/tool-editpolicy.html.en#edit_acl_by_task
and press the Enter key after moving the cursor line to currently running
Skype process at the Process State Viewer screen, and check that the policy
for currently running Skype process and the policy the policy file says are
identical.

Regards.

[Paolo Bolzoni]

About point one, I always used this line after modifying the files:

$ rm -f reject_000.log reject_003.log \
&& tomoyo-loadpolicy -ef </etc/tomoyo/exception_policy.conf \
&& tomoyo-loadpolicy -df </etc/tomoyo/domain_policy.conf

from the log directory and I double checked the syntax too.

I tried seeking for Skype in tomoyo-editpolicy after pressing
@ and all the rules appear....

It is really weird, what can I check too?

Cheers,
Paolo

[Tetsuo Handa]

Post by Paolo Bolzoni
I tried seeking for Skype in tomoyo-editpolicy after pressing
@ and all the rules appear....

Well, I think that the "file create" denial logs are caused by mode mismatch.

The policy says 0666

file create @SKYPE_FILES 0666

while the denial log says 0600

file create /home/paolo/.Skype/shared_dynco/dc.lock 0600

. You might want to change

file create @SKYPE_FILES 0666

to

file create @SKYPE_FILES 0600-0666

.

But you are still seeing the "file read" denial logs, aren't you?
Then, try running Skype process while running tomoyo-queryd on a terminal
application. tomoyo-queryd should show you which request is about to be
rejected by TOMOYO. http://tomoyo.sourceforge.jp/2.5/chapter-7.html.en#7.3

[Paolo Bolzoni]

Thanks, the "file create" problem was the culprit.
There was some other fine tune to do, but it works fine now.

Thanks again!
Paolo


On Mon, Apr 1, 2013 at 3:26 PM, Tetsuo Handa <

Post by Tetsuo Handa

Post by Paolo Bolzoni
I tried seeking for Skype in tomoyo-editpolicy after pressing
@ and all the rules appear....

Well, I think that the "file create" denial logs are caused by mode mismatch.
The policy says 0666
while the denial log says 0600
file create /home/paolo/.Skype/shared_dynco/dc.lock 0600
. You might want to change
to
.
But you are still seeing the "file read" denial logs, aren't you?
Then, try running Skype process while running tomoyo-queryd on a terminal
application. tomoyo-queryd should show you which request is about to be
rejected by TOMOYO. http://tomoyo.sourceforge.jp/2.5/chapter-7.html.en#7.3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sourceforge.jp/mailman/archives/tomoyo-users-en/attachments/20130402/2bc602e0/attachment.htm