Toshiharu Harada
harad****@nttda*****
Fri Nov 26 17:19:37 JST 2010
TOMOYO
Fork(2010/11/26 16:51), Jamie Nguyen wrote:
> [moved discussion to dev-ML]
Thank you for moving. I hope you like new home. :-)
>> I prefer unifying interface for audit logs rather than adding new interfaces.
>
> Yes, I totally agree.
>
>> What about renaming /proc/ccs/grant_log and /proc/ccs/reject_log to
>> /proc/ccs/audit (and add a field for telling this log is generated by "found"
>> or by "not found")?
You are right. The current file names, grant_log and reject_log
do not express their true meaning. "found" or "matched" are
more correct and what "reject_log" means they were not defined.
It might be a good chance to consider renaming log file names.
>> The ccs-auditd reads all logs from /proc/ccs/audit and sorts by
>> "directive name" (e.g. use_profile/use_group) and/or "access control mode"
>> (e.g. "mode=disabled") and/or "profile number" (e.g. "profile=0") and writes to
>> specified files. We will want a configuration file like syslog.conf .
>
> I think this could be nice.
>
> I still believe that the default profiles should be changed. If I run
> ccs-auditd and set all domains to Disabled Mode, then I don't expect
> anything at all to be written to files in /var/log, regardless of what
> name or role the log files are, and regardless of what /proc interface
> the log files are drawn from. If the mode is named "Disabled Mode"
> then my expectation is that the logging of any domain with this mode
> should be completely disabled. I speak purely about logging to
> /var/log. What goes on in /proc is a different matter, which I shall
> discuss separately at the end of this email.
>
> In my mind, here is how a user would make use of logs in /var/log/tomoyo:
> 1) See access requests that violate domain policy (reject.log)
> 2) Take appropriate action (e.g. allow in domain policy, or manage in
> realtime with ccs-queryd)
I think there is another use of logs.
3) Data to generate a domain policy
You might think that you don't need that because you use ccs-editpolicy,
however not every information can be found in the editor.
Actually, Tetsuo is planning to eliminate the "learning mode"
in the future. :-)
Changing default behavior for ccs-audit not to save domain
creating logs, but in that case users will never see them.
So, I personally prefer making default behavior to save
domain creation logs and provide a way to drop them for users
who do not want to see them (like you).
> This is essentially the primary use case of logs in /var/log/tomoyo.
> Thus, the logfile containing access requests that violate domain
> policy should contain only this information and nothing else, and only
> for domains that matter. The domains set to Disabled Mode or Learning
> Mode do not matter in this use case. There is also no reason for
> domain creation information to reside in the same log file.
>
> I still think the simplest solution would be to change the default
> profiles to something like this:
>
> 0-COMMENT=-----Disabled Mode-----
> 0-PREFERENCE={ max_grant_log=0 max_reject_log=0 max_learning_entry=0
> enforcing_penalty=0 }
> 0-CONFIG={ mode=disabled grant_log=no reject_log=no }
> 1-COMMENT=-----Learning Mode-----
> 1-PREFERENCE={ max_grant_log=0 max_reject_log=0
> max_learning_entry=2048 enforcing_penalty=0 }
> 1-CONFIG={ mode=learning grant_log=no reject_log=no }
> 2-COMMENT=-----Permissive Mode-----
> 2-PREFERENCE={ max_grant_log=0 max_reject_log=1024
> max_learning_entry=2048 enforcing_penalty=0 }
> 2-CONFIG={ mode=permissive grant_log=no reject_log=yes }
> 3-COMMENT=-----Enforcing Mode-----
> 3-PREFERENCE={ max_grant_log=0 max_reject_log=1024
> max_learning_entry=2048 enforcing_penalty=0 }
> 3-CONFIG={ mode=enforcing grant_log=no reject_log=yes }
>
> This would ensure that if a user runs init_policy and starts the
> ccs-auditd daemon, then the logs in /var/log/tomoyo won't get filled
> with information even though all domains are set to Disabled Mode.
>
> I think Learning Mode should receive the same treatment. This is the
> workflow that makes sense to me:
>
> 1) Identify a domain
> 2) Switch domain to Learning Mode to identify access requirements
> 3) Adjust policy
> 4) Switch domain to Permissive Mode to identify access rejections that
> you want to allow
> 5) Adjust policy
> 6) Switch domain to Enforcing Mode
> 7) Watch for further policy violations
> 8) Repeat 1) to 7) for another domain
>
> Using such a workflow, Disabled Mode and Learning Mode both do not
> have a requirement for logs in /var/log/tomoyo. Only at step 4 when
> switching to Permissive Mode should log files in /var/log/tomoyo be
> written to. This information can then be used to refine policy
> further. The above workflow represents both what a new user will do
> after init_policy, as well as a user refining their system with some
> domains already set to Enforcing Mode and others still in Disabled
> Mode. In the latter case, the existing information in
> /var/log/tomoyo/reject.log would be obfuscated by the irrelevant
> information from domains in Disabled/Learning Mode.
>
> You will also note, from the default profiles that I suggested above,
> that I have set max_grant_log=0 for every profile. Since grant_log=no
> is the default for every profile, then max_grant_log=0 seems to be a
> sane default too. I assume that there are memory savings if you set
> this to 0. If there are no memory savings, then it shouldn't matter if
> the default remains 1024. In addition I have changed
> max_learning_entry=0 in the Disabled Mode, to truly represent its role
> as "Disabled".
>
> If the default profiles are changed, then the interfaces in /proc/ccs
> could probably stay as they are. Since the options in the profiles
> refer to grant_log=no and reject_log=yes, it makes sense (and is
> probably simpler) to have a separate /proc/ccs/grant_log and
> /proc/ccs/reject_log. I don't think I really mind what you do with the
> interfaces in /proc/ccs, as long as the log files in /var/log/tomoyo
> are not being written to by domains in Disabled/Learning Mode. I can
> change this easily myself of course by editing the profiles, but I
> think the default behaviour should be changed.
>
> Kind regards
>
> _______________________________________________
> tomoyo-dev-en mailing list
> tomoy****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
Regards,
Toshiharu Harada
harad****@nttda*****