Jamie Nguyen
dysco****@gmail*****
Sat Nov 27 03:21:40 JST 2010
TOMOYO
ForkHi,
I thought a bit more about the naming of the interfaces
/proc/ccs/grant_log and /proc/ccs/reject_log. Domains make requests
(e.g. read/write/execute) that are either defined in policy or are not
defined in policy. If the permissions do not include this request (and
domain is in Enforcing Mode), it is denied. I name it request, because
the domain "requests" permission from TOMOYO, and is then allowed or
denied. Thus more accurate names would be something like
/proc/ccs/defined_requests and /proc/ccs/undefined_requests. But
combining these interfaces into /proc/ccs/audit I think is the
cleanest solution. All requests made by domains are recorded here,
whether defined in policy or not. /usr/sbin/ccs-auditd can then be
used to sort through this information.
Tetsuo Handa wrote:
> Your workflow assumes that all domains are defined before reaching
> step 1. But actually, we have to create domains as needed.
> If domain creation logs are not preserved for disabled/learning
> modes, we cannot create domains from audit logs.
You are right. On second thoughts I think it is important to have such
a log recording details of domains not defined in policy, although it
should be renamed to something like
/var/log/tomoyo/undefined_requests.log . This would function much the
same as /var/log/tomoyo/reject.log but with a name that more closely
reflects its role. I also want to suggest that the default logfile
names should be changed from .txt to .log as log files found in
/var/log generally take the format of {NAME}.log . The
/var/log/tomoyo/grant.log should be renamed to
/var/log/tomoyo/defined_requests.log
> My preference is to keep these lines in order to keep ability to
> create domain policy from /var/log/tomoyo/reject_log.conf .
> Your preference is to drop these lines in order to save disk storage
> and to avoid obfuscation by the irrelevant information.
This is basically solved by the default profiles for Disabled Mode and
Learning Mode being set to reject_log=no and grant_log=no, which is
included in your patch :-)
I think it would be good to have the ability to configure ccs-auditd
more finely. I think the default for ccs-auditd to write both
/var/log/tomoyo/defined_requests.log and
/var/log/tomoyo/undefined_requests.log should be changed. For users
that do not require defined_requests.log, sending the output of one
stream to /dev/null is an inefficient solution. It should be possible
to disable competely this particular action of ccs-auditd so that it
only sends output to undefined_requests.log without processing the
other. This is basically automatically solved by combining interfaces
into /proc/ccs/auditd as only relevant information needs to be parsed.
Irrelevant information will be ignored by ccs-auditd.
This could be done from command line, but I think all command line
options should be removed and these options should placed into a
config file (e.g. /etc/ccs/auditd.conf). There should be options of
whether ccs-auditd should process defined/undefined requests and the
location of the resulting log files. Having such a config file will
also allow a number of other options, such as using multiple log files
depending on profile number (e.g. undefined_requests_2.log for
Permissive Mode domains and undefined_requests_3.log for Enforcing
Mode domains). This could be done by profile number match, so that
custom profiles created by the user can also be managed using
/etc/ccs/auditd.conf . Since ccs-auditd is best used as a daemon,
providing the ability to configure it in a config file rather than
editing the rc.d script itself is a gain in usability. If a
distribution were to ship ccs-tools and tomoyo enabled kernel, it
would make sense to provide a pre-written daemon that can be enabled
or disabled as a 'service'. Not having a config file makes the
behaviour of this service much harder to change from the default
provided by the distribution.
> After applying above patch, /proc/ccs/audit will include
>
> (1) Logs of access requests which were found in the domain policy.
> (Currently sent to /proc/ccs/grant_log .)
>
> (2) Logs of access requests which were not found in the domain policy.
> (Currently sent to /proc/ccs/reject_log .)
>
> (3) Logs of domain creation requests which were not found in the domain policy.
> (Currently sent to /proc/ccs/reject_log .)
>
> (1) and (2) are generated by learning/permissive/enforcing modes
> because disabled mode does not check permissions.
> (3) is genareted by disabled/learning/permissive/enforcing modes
> because domain transition has to be performed regardless of modes and
> a new domain has to be added to domain policy if domain to transit to
> was not found in the domain policy.
I like the new default profile for Disabled Mode in your patch. It is
now truly "Disabled". I think (3) above is fine for Disabled Mode.
Domain creation must be logged otherwise the tree of domains that
appears in the "Domain Transition Editor" screen would be empty,
correct? And with the new default profile for Disabled Mode in your
patch, this information will not obscure more relevant information.
So in summary, here are changes that I think should be made in
addition to the patch you posted:
(1) rename logs to /var/log/tomoyo/defined_requests.log and
/var/log/tomoyo/undefined_requests.log or similar
(2) move configuration of ccs-auditd from command line to config file
/etc/ccs/auditd.conf or similar
(3) add further configurability to ccs-auditd
Kind regards