Jamie Nguyen wrote:
> Tetsuo Handa wrote:
> > We don't need to change {path,number,address}_group in kernel's policy
> > syntax.
> > These {file,head,tail,number,address}_pattern are proposed for
> > ccs-patternize
> > in order to unify like "some_keyword new_pattern old_pattern" (or
> > "some_keyword
> > old_pattern to new_pattern"). We can propose whatever syntax/keyword.
>
> Yes, perhaps the syntax that sed and other replacement commands use
> would be appropriate, using "some_keyword old_pattern new_pattern".
>
> "command old new" is the format used by many Linux commands (e.g.
> cp, mv, ln, diff and so on). The current situation in exception policy
> is "keyword new old" and this works well with what is displayed on
> screen. For example, "path_group GROUP0 /tmp/\?\?\?" will be displayed
> as written. This is contrary with syntax of other Linux commands, but
> changing syntax to "keyword old new" could be confusing as entering:
> path_group /tmp/\?\?\? GROUP0
> would then be displayed in exception policy editor as:
> path_group GROUP0 /tmp/\?\?\?
> Might be confusing, but this would provide continuity between
> ccs-patternize/exception policy/other Linux command syntax.
Excuse me, but {path,number,address}_group are not "keyword new old" format.
They are "keyword group_name group_member" format. I explain below.
> The other option is to just keep things as they are for exception
> policy syntax and match ccs-patternize syntax to exception policy
> syntax "keyword new old". The problem is that for exception policy,
> "new" before "old" makes more sense (due to the display in exception
> policy editor), but for ccs-patternize, "old" before "new" makes more
> sense (due to syntax of other similar replacement commands).
>
> My opinion is that syntax should be "keyword old new" for both
> exception policy and ccs-patternize, but to keep exception policy
> editor display as it is, without reordering the fields.
OK. Let's assume "keyword old new" for ccs-patternize.
There are several keywords that take two arguments.
(Argument may use wildcards or a range.)
aggregator old_program new_program
path_group path_group_name path_group_member
number_group number_group_name number_group_member
address_group address_group_name address_group_member
are in exception policy and
file_pattern old_pathname new_pathname
file_pattern old_pathname @path_group_name
head_pattern old_pathname new_pathname
head_pattern old_pathname @path_group_name
tail_pattern old_pathname new_pathname
tail_pattern old_pathname @path_group_name
number_pattern old_number new_number
number_pattern old_number @number_group_name
address_pattern old_address new_address
address_pattern old_address @address_group_name
will be in configuration file for ccs-patternize.
'aggregator' converts 'old_program' into 'new_program' when checking execute
permission and calculating domainname to transit to.
It acts like 'mv old_program new_program'.
'file_pattern'/'head_pattern'/'tail_pattern' will convert 'old_pathname' into
'new_pathname' (or 'old_pathname' into '@path_group_name'). It acts like
'mv old_pathname new_pathname' (or 'mv old_pathname @path_group_name').
However, 'path_group'/'number_pattern'/'address_pattern' do not convert
'{path,number,address}_group_name' into '{path,number,address}_group_member'.
They do not act like
'mv {path,number,address}_group_name {path,number,address}_group_member'
because {path,number,address}_group_name is a container's name and
{path,number,address}_group_member is an element in the container.
The name of a container is referred from domain policy by using '@' mark (i.e.
@{path,number,address}_group_name ). Therefore, domain policy looks like
file read @WWW_CONTENTS
and exception policy looks like
path_group WWW_CONTENTS /var/www/html/\*\-.\*
path_group WWW_CONTENTS /var/www/html/\{\*\-.\*\}/\*\-.\*
path_group WWW_CONTENTS /home/\*/public_html/\*\-.\*
path_group WWW_CONTENTS /home/\*/public_html/\{\*\-.\*\}/\*\-.\*
(and TOMOYO compares the requested pathname with
/var/www/html/\*\-.\*
/var/www/html/\{\*\-.\*\}/\*\-.\*
/home/\*/public_html/\*\-.\*
/home/\*/public_html/\{\*\-.\*\}/\*\-.\*
when encountered
@WWW_CONTENTS
upon permission check).
As far as I know, a pathname will not start with '@' because there is no
filesystem which name starts with '@'. (TOMOYO uses '\000' for representing
Unix domain socket's abstract namespace while /proc/net/unix uses '@'.)
Therefore, we can tell whether @WWW_CONTENTS in the domain policy refers a
group or not.
> > Typical replacement commands (e.g. sed) take both old pattern and new
> > pattern.
> > But currently {file,head,tail}_pattern does not take old pattern because we
> > regard new pattern == old pattern.
> >
> > I removed file_pattern keyword support from TOMOYO 1.8's kernel in order to
> > implement more flexible replacement commands. I think that taking both old
> > pattern and new pattern allows use of extended replacement (like sed
> > command's
> > reference functionality) if ccs-patternize (in the future) supports extended
> > expressions.
>
> Can you give example usage?
>
Assuming "keyword old new" order, a pattern like
file_pattern /tmp/orbit-\[name=\*\]/\* @TMP_ORBIT_\[name\]
would replace
file create
/tmp/orbit-kumaneko/bonobo-activation-register-3949ef88ee5480269e3f396700000101.lock
0700
with
file create @TMP_ORBIT_kumaneko 0700
.
> >>> Also, maybe we want domainname matching like ccs-auditd's sorting rule.
> >>
> >> Do you mean so that patternizing only occurs for specified domain?
> >> Current situation is that all matching entries get patternized
> >> regardless of domain. If implemented, it could be useful for example
> >> in the case that there are several domains wanting to access some
> >> resource that you want to block access to, but want to allow a single
> >> domain to access this resource. However, policy is reasonably easy to
> >> manage by hand using diff and editor so I am not urgently requiring
> >> this feature.
> >
> > I see. Users can use ccs-selectpolicy for picking up only specific domains.
>
> Can you provide example usage for domainname matching that you suggested?
ccs-selectpolicy -r '<kernel> /usr/sbin/sshd' < /path/to/domain/policy >
/tmp/1
ccs-patternize < /tmp/1 > /tmp/2
ccs-diffpolicy /tmp/1 /tmp/2 > /tmp/3
less /tmp/3
ccs-loadpolicy -d < /tmp/3
will patternize only '<kernel> /usr/sbin/sshd' and its descendant domains.
Do we want keyword matching (e.g. patternize only "file create" entries)
(though we can pick them up by
awk ' { if ($1 == "<kernel>" || ($1 == "file" && $2 == "create")) print $0; }
'
)? If we want keyword matching, syntax similar to ccs-auditd is needed.
Regards.
_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
