Discussion:
[tomoyo-users-en 582] /var/log/tomoyo and updating apps
(too old to reply)
Claus Reheis
2014-03-16 19:03:42 UTC
Permalink
Raw Message
Dear Tomoyo user list,

After playing around with "Tomoyo Linux" since one week I have to say
that I really enjoy analyzing my system and confining applications with
Tomoyo Linux.

After putting some applications in "permissive mode" I wanted to take a
look at the "reject logs" in /var/log/tomoyo/ and was surprised how big
the file reject_001.log has grown... 6.9GB!!!
This file is from the "learning mode" as far as I understand!?
Luckily I habe a big hard drive in my laptop, but when this log file
continue to grow at this rate I will be out of space soon!
What is filling up this file so fast and what can I do about it?

As Mageia is providing Firefox ESR, we have a Version what does not get
upgraded ad often as it happens in other distributions and when I see
this from the perspective of a Tomoyo Linux user, I even appreciate it
more to have less frequent changes.

Particular I was wondering if I have a Tomoyo policy for the domain:

/usr/lib64/firefox-24.3.0/plugin-container

if there there a way to do some wildcard magic what makes it possible
that the policy automatically adopts to a new version/path like

/usr/lib64/firefox-24.4.0/plugin-container

or do I have to create and edit a new policy every time Firefox gets
updated?

Thank you!

rehcla
Tetsuo Handa
2014-03-17 11:10:12 UTC
Permalink
Raw Message
Post by Claus Reheis
After playing around with "Tomoyo Linux" since one week I have to say
that I really enjoy analyzing my system and confining applications with
Tomoyo Linux.
Yes, TOMOYO is a powerful tool for analyzing/understanding Linux systems. ;-)
Post by Claus Reheis
After putting some applications in "permissive mode" I wanted to take a
look at the "reject logs" in /var/log/tomoyo/ and was surprised how big
the file reject_001.log has grown... 6.9GB!!!
This file is from the "learning mode" as far as I understand!?
Yes.
Post by Claus Reheis
Luckily I habe a big hard drive in my laptop, but when this log file
continue to grow at this rate I will be out of space soon!
What is filling up this file so fast and what can I do about it?
Probably /proc/$pid/ files and temporary files are filling up this file.
You can use tomoyo-patternize utility (see /etc/tomoyo/tools/patternize.conf
for configuration) for converting such pathnames to patterns.

http://tomoyo.sourceforge.jp/2.5/chapter-6.html
Post by Claus Reheis
As Mageia is providing Firefox ESR, we have a Version what does not get
upgraded ad often as it happens in other distributions and when I see
this from the perspective of a Tomoyo Linux user, I even appreciate it
more to have less frequent changes.
Unless dependency changes, there will be little with updating TOMOYO's
configuration when updating software packages. There is tomoyo-queryd
utility which you can use for interactively judging exceptional requests
which happen while updating software packages.
Post by Claus Reheis
/usr/lib64/firefox-24.3.0/plugin-container
if there there a way to do some wildcard magic what makes it possible
that the policy automatically adopts to a new version/path like
/usr/lib64/firefox-24.4.0/plugin-container
or do I have to create and edit a new policy every time Firefox gets
updated?
You can use aggregator directive (see
/etc/tomoyo/policy/current/exception_policy.conf for configuration).

aggregator /usr/lib/firefox-\*/plugin-container /usr/lib/firefox/plugin-container

The "file execute" permission and domainname can be wildcarded by the
aggregator directive. Other permissions (e.g. "file read") can be wildcarded
by tomoyo-patternize utility.
clausreheis
2014-03-17 11:25:55 UTC
Permalink
Raw Message
Hello Tetsuo Handa,
Post by Tetsuo Handa
Post by Claus Reheis
After playing around with "Tomoyo Linux" since one week I have to say
that I really enjoy analyzing my system and confining applications with
Tomoyo Linux.
Yes, TOMOYO is a powerful tool for analyzing/understanding Linux
systems.
Post by Tetsuo Handa
;-)
Post by Claus Reheis
After putting some applications in "permissive mode" I wanted to take a
look at the "reject logs" in /var/log/tomoyo/ and was surprised how big
the file reject_001.log has grown... 6.9GB!!!
This file is from the "learning mode" as far as I understand!?
Yes.
Post by Claus Reheis
Luckily I habe a big hard drive in my laptop, but when this log file
continue to grow at this rate I will be out of space soon!
What is filling up this file so fast and what can I do about it?
Probably /proc/$pid/ files and temporary files are filling up this file.
You can use tomoyo-patternize utility (see
/etc/tomoyo/tools/patternize.conf
Post by Tetsuo Handa
for configuration) for converting such pathnames to patterns.
http://tomoyo.sourceforge.jp/2.5/chapter-6.html
Can I safely delete the logfiles from time to time until I figured it out
how to manage the tomoyo-patternize utility?
Post by Tetsuo Handa
Post by Claus Reheis
As Mageia is providing Firefox ESR, we have a Version what does not get
upgraded ad often as it happens in other distributions and when I see
this from the perspective of a Tomoyo Linux user, I even appreciate it
more to have less frequent changes.
Unless dependency changes, there will be little with updating
TOMOYO's
Post by Tetsuo Handa
configuration when updating software packages. There is tomoyo-
queryd
Post by Tetsuo Handa
utility which you can use for interactively judging exceptional requests
which happen while updating software packages.
Post by Claus Reheis
/usr/lib64/firefox-24.3.0/plugin-container
if there there a way to do some wildcard magic what makes it
possible
Post by Tetsuo Handa
Post by Claus Reheis
that the policy automatically adopts to a new version/path like
/usr/lib64/firefox-24.4.0/plugin-container
or do I have to create and edit a new policy every time Firefox gets
updated?
You can use aggregator directive (see
/etc/tomoyo/policy/current/exception_policy.conf for configuration).
aggregator /usr/lib/firefox-\*/plugin-container
/usr/lib/firefox/plugin-container
The "file execute" permission and domainname can be wildcarded by the
aggregator directive. Other permissions (e.g. "file read") can be wildcarded
by tomoyo-patternize utility.
Greetings from Austria,
rehcla.mailinglist
2014-03-21 14:25:23 UTC
Permalink
Raw Message
Hello!


After spending the last days with adding rules to my

/etc/tomoyo/tools/patternize.conf

and successfully reducing the size of the content of my /var/log/tomoyo/
directory, I got the expected update of my firefox package!

While I was busy playing with wildcards, I did put firefox in learning mode
and did the update.
I intended to delete the domain for Firefox 24.3 and just editing a new one
for 24.4!
This worked out half way, but I still have the 24.3 domains left in the policy
editor looking like:

( /usr/lib64/firefox-24.3.0/firefox )
( /usr/lib64/firefox-24.3.0/plugin-container )

Then I decided that I take a closer look to you last mail and I followed you
advice with adding:

aggregator /usr/lib64/firefox-2\$.\$.\$/plugin-container /usr/lib64/plugin-
container

to my /etc/tomoyo/policy/current/exception_policy.conf

but I still see the firefox 24.3 domains!

After looking through:

/etc/tomoyo/policy/current/domain_policy.conf

I saw some firefox 24.3 lines there too!

What can I do now?
Sorry for being so hasty with deleting the domains in the policyeditor what
probably brought me in this ?little? mess :-/

Greetings
Post by Tetsuo Handa
Post by Claus Reheis
After playing around with "Tomoyo Linux" since one week I have to say
that I really enjoy analyzing my system and confining applications with
Tomoyo Linux.
Yes, TOMOYO is a powerful tool for analyzing/understanding Linux systems. ;-)
Post by Claus Reheis
After putting some applications in "permissive mode" I wanted to take a
look at the "reject logs" in /var/log/tomoyo/ and was surprised how big
the file reject_001.log has grown... 6.9GB!!!
This file is from the "learning mode" as far as I understand!?
Yes.
Post by Claus Reheis
Luckily I habe a big hard drive in my laptop, but when this log file
continue to grow at this rate I will be out of space soon!
What is filling up this file so fast and what can I do about it?
Probably /proc/$pid/ files and temporary files are filling up this file.
You can use tomoyo-patternize utility (see /etc/tomoyo/tools/patternize.conf
for configuration) for converting such pathnames to patterns.
http://tomoyo.sourceforge.jp/2.5/chapter-6.html
Post by Claus Reheis
As Mageia is providing Firefox ESR, we have a Version what does not get
upgraded ad often as it happens in other distributions and when I see
this from the perspective of a Tomoyo Linux user, I even appreciate it
more to have less frequent changes.
Unless dependency changes, there will be little with updating TOMOYO's
configuration when updating software packages. There is tomoyo-queryd
utility which you can use for interactively judging exceptional requests
which happen while updating software packages.
Post by Claus Reheis
/usr/lib64/firefox-24.3.0/plugin-container
if there there a way to do some wildcard magic what makes it possible
that the policy automatically adopts to a new version/path like
/usr/lib64/firefox-24.4.0/plugin-container
or do I have to create and edit a new policy every time Firefox gets
updated?
You can use aggregator directive (see
/etc/tomoyo/policy/current/exception_policy.conf for configuration).
aggregator /usr/lib/firefox-\*/plugin-container
/usr/lib/firefox/plugin-container
The "file execute" permission and domainname can be wildcarded by the
aggregator directive. Other permissions (e.g. "file read") can be wildcarded
by tomoyo-patternize utility.
Tetsuo Handa
2014-03-21 16:19:20 UTC
Permalink
Raw Message
Post by rehcla.mailinglist
Hello!
After spending the last days with adding rules to my
/etc/tomoyo/tools/patternize.conf
and successfully reducing the size of the content of my /var/log/tomoyo/
directory, I got the expected update of my firefox package!
While I was busy playing with wildcards, I did put firefox in learning mode
and did the update.
I intended to delete the domain for Firefox 24.3 and just editing a new one
for 24.4!
This worked out half way, but I still have the 24.3 domains left in the policy
( /usr/lib64/firefox-24.3.0/firefox )
( /usr/lib64/firefox-24.3.0/plugin-container )
Domains in parenthesis are shown for keeping tree indent.
They will disappear when all child domains are deleted using 'd' key.
http://tomoyo.sourceforge.jp/2.5/tool-editpolicy.html#missing_domain

In case you are misunderstanding, I explain again.
tomoyo-editpolicy will edit on-memory configuration if executed without
the location of on-disk configuration (i.e. /etc/tomoyo/ ). Therefore, please
run tomoyo-savepolicy when you edited on-memory configuration using
tomoyo-editpolicy in order to copy on-memory configuration to on-disk.
Post by rehcla.mailinglist
Then I decided that I take a closer look to you last mail and I followed you
aggregator /usr/lib64/firefox-2\$.\$.\$/plugin-container /usr/lib64/plugin-
container
to my /etc/tomoyo/policy/current/exception_policy.conf
but I still see the firefox 24.3 domains!
I think

/usr/lib64/firefox-\*/plugin-container

is better because Firefox will someday reach version 30.0.

Also, if you edited on-disk configuration (e.g.
/etc/tomoyo/policy/current/exception_policy.conf ), please run
tomoyo-loadpolicy in order to copy on-disk configuration to on-memory.

# tomoyo-loadpolicy -e < /etc/tomoyo/policy/current/exception_policy.conf

Finally, please run tomoyo-pstree command and check that currently running
processes are in domains you intended. If they are not in domains you intended
(e.g. some firefox instance remains in /usr/lib64/firefox-24.3.0/firefox or
/usr/lib64/firefox-24.4.0/firefox ), please restart such process.

# tomoyo-pstree -a
Post by rehcla.mailinglist
/etc/tomoyo/policy/current/domain_policy.conf
I saw some firefox 24.3 lines there too!
/etc/tomoyo/policy/current/domain_policy.conf is on-disk configuration.
This file will be synchronized with on-memory configuration by running
tomoyo-savepolicy .
Post by rehcla.mailinglist
What can I do now?
Sorry for being so hasty with deleting the domains in the policyeditor what
probably brought me in this ?little? mess :-/
Greetings
Loading...