Jamie Nguyen
dysco****@gmail*****
Wed Dec 8 18:08:35 JST 2010
TOMOYO
ForkTetsuo Handa wrote:
> Excuse me, but {path,number,address}_group are not "keyword new old" format.
> They are "keyword group_name group_member" format. I explain below.
Sorry, my oversight.
> 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.
OK, so path_group defines the group_name followed by the group_member.
If comparing with another similar command, "gpasswd -a jamie audio"
defines group_member before group_name. However, I think I prefer your
syntax, especially due to how entries are displayed in exception
policy.
>> > 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
Yes, this sounds good.
>> >>> 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.
Oh right, I understand. I think this could benefit users, especially
because not all are familiar with awk. However, it depends on how
complex it is to implement and whether it adds a lot of complexity to
the workflow. If I understand correctly, keyword matching rules will
be placed into ccs-patternize configuration file?
Kind regards.