Tetsuo Handa wrote:
> Regarding ccs-auditd , we have three lines and we can refer these lines using
> three lines "header", "domain", "acl" respectively.
>
> header.contains("granted=yes") write("/dev/null")
>
> header.contains("granted=no") header.contains("profile=1")
> write("/var/log/tomoyo/profile001.log")
>
> header.contains("granted=no") acl[1].equals("file") acl[2].equals("create")
> write("/var/log/tomoyo/file.create.log")
>
> header.contains("granted=no") domain.starts("<kernel> /usr/sbin/httpd")
> write("/var/log/tomoyo/apache.log")
>
> header.contains("granted=no") domain.equals("<kernel> /usr/sbin/sshd")
> write("/var/log/tomoyo/sshd.log")
>
> or using multi lines
>
> header.contains: granted=yes
> write: /dev/null
>
> header.contains: granted=no
> header.contains: profile=1
> write: /var/log/tomoyo/profile001.log
>
> header.contains: granted=no
> acl[1].equals: file
> acl[2].equals: create
> write: /var/log/tomoyo/file.create.log
>
> header.contains: granted=no:
> domain.starts: <kernel> /usr/sbin/httpd
> write: /var/log/tomoyo/apache.log
>
> header.contains: granted=no:
> domain.equals: <kernel> /usr/sbin/sshd
> write: /var/log/tomoyo/sshd.log
I definitely prefer multi-line format. It is more legible and much
easier to work with.
> Regarding ccs-patternize , we can use "domain" and "acl" respectively.
> (Unlike ccs-auditd , we don't have header line.)
>
> domain.starts("<kernel> /usr/sbin/httpd") acl[1].equals("file")
> convert.path("/var/www/html/\*", "@WWW_CONTENTS")
>
> convert.path("/etc/mtab~\$", "/etc/mtab~\$")
>
> or using multi lines
>
> domain.contains: <kernel> /usr/sbin/httpd
> acl[1].starts: file
> convert.path: /var/www/html/\* @WWW_CONTENTS
>
> convert.path: /etc/mtab~\$ /etc/mtab~\$
Again, multi-line format is much better.
> If you feel that this kind of keywords and syntaxes
> (this is a programming language) is too difficult for users,
> maybe ccs-patternize should not deal with keyword matching.
>
>
> What keywords and syntaxes do you want to use?
With ccs-patternize, work flow need not change for users not wanting
to use complex keyword matching. "domain" and "acl" does not
specifically need to be specified. For users that do require more
complex keyword matching, having this functionality in ccs-patternize
could make life easier. While awk can be used to achieve a similar
goal, I think having ccs-patternize configuration file is much easier
to work with. It also provides a place to store commonly used patterns
that can be easily re-used across multiple systems to develop policy.
So in my opinion, keyword matching for ccs-patternize would be a very
good thing to implement.
>>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.
I've thought more about the syntax of path_group.
I notice that gpasswd -a jamie audio takes the syntax:
"keyword group_member group_name"
while the resulting entry in /etc/group takes the syntax:
"group_name ::: group_member"
If syntax for path_group were to be reversed from it's current syntax,
then it would be like:
"keyword group_member group_name"
and the view in exception policy editor would be:
"group_name group_member"
Thus it would be consistent with gpasswd syntax on command line and in
/etc/group. I also feel that with current syntax (keyword group_name
group_member), it suggests that defining group_name is exclusive and
not additive, and group_member becomes the exclusive member of that
group. For example, in BASH, string=variable then defines the string
exclusively as that variable. Excuse the bad example. What do you
think? This issue is not as important as others being discussed, but I
thought I'd lay my thoughts on the table. Obviously, changing syntax
should only be done if really necessary.
Kind regards.
_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
