Tetsuo Handa
from-****@I-lov*****
Thu Dec 23 15:16:46 JST 2010
TOMOYO
ForkI started updating documentation using tags/htdocs/1.8-tmp/ on SVN repository.
I reedited content in learning.html and tuning.html because handling temporary
files is inevitable before using permissive mode.
Jamie Nguyen wrote:
> Tetsuo Handa wrote:
> > Below is the changelog as of revision 4215.
> >
> > Policy file's location has moved from /etc/ccs/ directory to
> > /etc/ccs/policy/YY-MM-DD.hh:mm:ss/ directory. A symlink named "current" which
> > points to YY-MM-DD.hh:mm:ss/ directory is created under /etc/ccs/policy/
> > directory so that users can switch policy files by manipulating only one
> > symlink. Also, a symlink named "previous" which points to previous
> > YY-MM-DD.hh:mm:ss/ directory is created under /etc/ccs/policy/ directory
> > so that users can easily find previous back up. For compatibility and user's
> > convenience, symlinks which point to policy/current/ are created in
> > /etc/ccs/ directory.
>
> The policy files made /etc/ccs very cluttered, but the new location is
> great. "previous" is an excellent addition.
>
Thanks. I intentionally didn't remove /etc/ccs/domain_policy.conf
/etc/ccs/exception_policy.conf /etc/ccs/profile.conf /etc/ccs/manager.conf and
/etc/ccs/stat.conf so that users and programs can read these files using old
pathnames.
ccs-savepolicy saves these files into /etc/ccs/policy/YY-MM-DD.hh:mm:ss/
directory, but ccs-savepolicy will not be used in embedded environments.
In embedded environments, only ccs-init and ccs-editpolicy-agent will be used,
and policy files may not be stored in /etc/ccs/policy/YY-MM-DD.hh:mm:ss/
directory.
Therefore, I didn't make ccs-init and ccs-loadpolicy to read policy files from
/etc/ccs/policy/current/ directory.
> I have done some testing with ccs-patch and ccs-tools from subversion.
>
> > /usr/sbin/ccs-patternize
> > Changed syntax and keywords.
> > Added conditional rewriting support.
> > Added leading pathname matching and trailing pathname matching support.
> > Use /etc/ccs/tools/patternize.conf rather than command line arguments.
> > First command line argument was not used by error.
> > The "file getattr" permission was not handled by error.
>
> Seems to work fine.
>
> I notice that "rewrite head_pattern old_pattern new_pattern" will
> break if "old_pattern" does not end in with a "/". Is this behaviour
> intentional?
>
Yes.
head_pattern will fail if "old_pattern" does not end with a "/" and
tail_pattern will fail if "old_pattern" does not start with a "/".
> Also, would it be easy to implement something like:
>
> domain.contains /usr/bin/firefox
> {
> 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
> }
>
> At the moment, "domain.contains /usr/bin/firefox" must be repeated
> before each rewrite line. Something like the above would allow it to
> be specified only once.
>
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.
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)?
> Regarding the commented instructions in
> /etc/ccs/tools/patternize.conf, perhaps a list of possible keywords
> could be added, like path_pattern, head_pattern etc.
>
OK. But we need to determine syntaxes/keywords first.
> > /usr/sbin/ccs-auditd
> > Use /proc/ccs/audit rather than /proc/ccs/grant_log and
> > /proc/ccs/reject_log (this change requires updated ccs-patch ).
> > Added conditional auditing support.
> > Use /etc/ccs/tools/auditd.conf rather than command line arguments.
>
> 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.
> > /usr/lib/ccs/init_policy
> > Create initial policy under /etc/ccs/policy/YY-MM-DD.hh:mm:ss/ directory.
> > Create initial userland configuration under /etc/ccs/tools/ directory.
>
> 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.
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
)?
Regards.