Tetsuo Handa
from-****@I-lov*****
Mon Dec 13 22:23:43 JST 2010
TOMOYO
ForkJamie Nguyen wrote:
> 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.
OK. I implemented it for ccs-auditd part. (Revision 4192.)
An audit log consists with three lines. You can refer the first line using
'Header' keyword, the second line using 'Domain' keyword, and the third line
using 'ACL' keyword.
Words in each line are separated by a space character. Therefore, you can use
'Header[index]', 'Domain[index]', 'ACL[index]' for referring index'th word of
the line. The index starts from 1, and 0 refers the whole line (i.e.
'Header[0]' = 'Header', 'Domain[0]' = 'Domain', 'ACL[0]' = 'ACL').
Sorting rules are defined using multi-lined chunks. A chunk is terminated by a
'Destination:' line which specifies the pathname to write the audit log when
all preceding conditions in that chunk have matched.
Note that an audit log is written to only first chunk which all
conditions in that chunk have matched.
Three operators are provided for conditional sorting.
'.contains:' is for 'fgrep keyword' match.
'.equals:' is for 'grep ^keyword$' match.
'.starts:' is for 'grep ^keyword' match.
Syntax and its equivalent expression in awk command are shown below.
Header.contains: substring
awk ' { if ( index( " "$0" " , " substring " ) > 0 ) ...; } '
Header[1].contains: substring
awk ' { if ( index( $1 , "substring" ) > 0 ) ...; } '
Header.starts: substring
awk ' { if ( index( $0" " , "substring " ) == 1 ) ...; } '
Header[2].starts: substring
awk ' { if ( index( $2 , "substring" ) == 1 ) ...; } '
Header.equals: line
awk ' { if ( $0 == "line" ) ...; } '
Header[3].equals: word
awk ' { if ( $3 == "word" ) ...; } '
Domain.contains: domainname
awk ' { if ( index( " "$0" " , " domainname " ) > 0 ) ...; } '
Domain[2].contains: /usr/sbin/
awk ' { if ( index ( $2 , "/usr/sbin/" ) > 0 ) ...; } '
Domain.starts: domainname
awk ' { if ( index ( $0" " , "domainname " ) == 1 ) ...; } '
Domain[2].starts: /usr/sbin/
awk ' { if ( index ( $2 , "/usr/sbin/" ) == 1 ) ...; } '
Domain.equals: <kernel> /usr/sbin/sshd
awk ' { if ( $0 == "<kernel> /usr/sbin/sshd" ) ...; } '
Domain[2].equals: /usr/sbin/sshd
awk ' { if ( $2 == "/usr/sbin/sshd" ) ...; } '
ACL.contains: substring
awk ' { if ( index ( " "$0" " , " substring " ) > 0 ) ...; } '
ACL[3].contains: substring
awk ' { if ( index ( $3 , "substring" ) > 0 ) ...; } '
ACL.starts: substring
awk ' { if ( index ( $0" " , "substring " ) == 1 ) ...; } '
ACL[1].starts: substring
awk ' { if ( index ( $1 , "substring" ) == 1 ) ...; } '
ACL.equals: line
awk ' { if ( $0 == "line" ) ...; } '
ACL[2].equals: word
awk ' { if ( $2 == "word" ) ...; } '
Note that regarding '.contains:' and '.starts:' operators, there is a
difference between scanning the whole line and scanning a word in that line.
The former case adds a space (in order to avoid matching (e.g.)
uid=0
with
task={ pid=3392 ppid=3388 uid=48 gid=48 euid=48 egid=48 suid=48 sgid=48 fsuid=48 fsgid=48 type!=execute_handler } argv={ "grep" "uid=0" "/tmp/users" }
) whereas the latter case does not (in order to allow matching (e.g.)
"/usr/sbin/" with "/usr/sbin/sshd").
Below is default configuration for /etc/ccs/tools/auditd.conf .
Any questions or comments?
# Discard all granted logs.
Header.contains: granted=yes
Destination: /dev/null
# Save rejected logs with profile=0 to /var/log/tomoyo/reject_000.log
Header.contains: profile=0
Destination: /var/log/tomoyo/reject_000.log
# Save rejected logs with profile=1 to /var/log/tomoyo/reject_001.log
Header.contains: profile=1
Destination: /var/log/tomoyo/reject_001.log
# Save rejected logs with profile=2 to /var/log/tomoyo/reject_002.log
Header.contains: profile=2
Destination: /var/log/tomoyo/reject_002.log
# Save rejected logs with profile=3 to /var/log/tomoyo/reject_003.log
Header.contains: profile=3
Destination: /var/log/tomoyo/reject_003.log
> >>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.
I won't change because the view in the policy editor is identical with the
view in a text editor. Policy files are provided in the form of plain ASCII
printable text so that users can edit using their favorite editors. Reversing
the order between the policy editor and other programs will confuse users.
Regards.