Jamie Nguyen
dysco****@gmail*****
Thu Dec 23 18:10:27 JST 2010
TOMOYO
ForkTetsuo Handa wrote:
> Well, we will want something like
>
> if {
> domain.contains /usr/bin/firefox
> acl.starts
> } then {
> rewrite path_pattern /home/jamie/.mozilla/ @FIREFOX-HOME
> rewrite path_pattern /home/jamie/.mozilla/\* @FIREFOX-HOME
> rewrite path_pattern /home/jamie/.mozilla/\{\*\}/ @FIREFOX-HOME
> rewrite path_pattern /home/jamie/.mozilla/\{\*\}/\* @FIREFOX-HOME
> }
>
> because users want to apply multiple conditions against multiple actions.
Yes, this would be good.
> Should we support userspace specific extended expression like \~ which refers
> uncompared substring of head_pattern/tail_pattern part so that users can
> specify like
>
> rewrite head_pattern /home/jamie/.mozilla/ @FIREFOX-HOME
>
> (drop uncompared substring in new_pattern) and
>
> rewrite head_pattern proc:/\$/task/\$/ proc:/\$/task/\$/\~
>
> (don't drop uncompared substring in new_pattern)?
Yes, sounds good. Would save many lines, as a lot of my patterns are like:
/foo/
/foo/\*
/foo/\{\*\}/
/foo/\{\*\}/\*
This could be done with one line:
rewrite head_pattern /foo/ @bar
>> I have the following in "/etc/ccs/tools/ccs-auditd.conf":
>>
>> header.contains profile=3
>> domain.contains /usr/bin/firefox
>> destination /var/log/tomoyo/firefox.log
>>
>> However, rejected access requests still go to
>> "/var/log/tomoyo/reject_003.log". Is my syntax incorrect?
>>
> Your syntax is correct. Did you write
>
> header.contains profile=3
> domain.contains /usr/bin/firefox
> destination /var/log/tomoyo/firefox.log
>
> lines before
>
> header.contains profile=3
> destination /var/log/tomoyo/reject_003.log
>
> lines? If so, that will be my bug.
Yes, when the firefox related lines go after reject_003.log then it
doesn't work. If I move the firefox lines before then it works fine.
>> After running "/usr/lib/ccs/init_policy", running "ccs-editpolicy"
>> will give the following error:
>>
>> "You need to register this program to /proc/ccs/manager to run this program."
>>
>> (This was also the behaviour of normal ccs-patch and ccs-tools before
>> subversion changes). The way I solved this was to reboot the computer.
>> What is the recommended method to register the program to
>> /proc/ccs/manager? I was unsure of the proper way to do this.
>
> /sbin/ccs-init is executed before /sbin/init starts, and /sbin/ccs-init copies
> /etc/ccs/manager.conf to /proc/ccs/manager . If no programs or domains were
> registered before /sbin/init starts, there is no solution but to reboot the
> computer.
The first time I was faced with this warning, I didn't know what I had
to do to register the program. I've changed the warning message in
ccs-loadpolicy.c to recommend a reboot.
Also, concerning warning messages, I have slightly changed some of the
warnings for ccs-patch 1.8.x to improve meaning/grammar. However, for
the 2.x branch, I am unsure where changes should go. From what I
understand, TOMOYO 2.3 is for kernel 2.6.36, and TOMOYO 2.4 is for
kernel 2.6.37 . Because any corrections I make are going to be purely
aesthetic, I think I will only make changes in TOMOYO before the next
merge window, which is TOMOYO 2.5 for kernel 2.6.38 . What is your
workflow for submitting patches for the merge window (e.g. when will
you start putting together the patches for next merge window) and
which directory of SVN do your patches go? I am guessing "tags/lkml".
> You can use /usr/sbin/ccs-loadpolicy for managing /proc/ccs/manager after
> /sbin/init starts (provided that /usr/sbin/ccs-loadpolicy was registered by
> /sbin/ccs-init ).
>
> echo '/path/to/program' >> /etc/ccs/policy/current/manager.conf
> /usr/sbin/ccs-loadpolicy m
>
> or
>
> echo '/path/to/program' | /usr/sbin/ccs-loadpolicy -m
>
> .
>
> At first, policy directory was hard coded and reading from stdin was not
> supported. But nowadays, policy location varies so much and reading from stdin
> is used commonly. Maybe it is time to make ccs-loadpolicy forget about policy
> directory.
> Is it OK to forbid ccs-loadpolicy without one of -d -e -m -p -s options
> (which results in forcing users to use pipe or redirection like
>
> ccs-loadpolicy -m < /etc/ccs/manager.conf
>
> rather than
>
> ccs-loadpolicy m
>
> )?
Yes, I think ccs-loadpolicy should require an option.
According to the man page, I notice that "m", "p" and "s" options do
not have the choice to include the "f" option. The man page reads:
p : Read from policy_dir/profile.conf and append to /proc/ccs/profile
m : Read from policy_dir/manage.conf and append to /proc/ccs/profile
s: Read from policy_dir/stat.conf and append to /proc/ccs/stat
I see that there is no "if (refresh_policy)" for these options, so
from my understanding they do not actually append, but instead
overwrite by default. I have changed ccs-loadpolicy options to reflect
this. Am right in thinking help2man will automatically reflect the
changes in the man page?
Kind regards