Hello Tetsuo Handa, Thanks for reply!
29.12.2012, 12:53, "Tetsuo Handa" <[email protected]>: > [email protected] wrote: > >> 1. I thought such scheme will require 12 rules, but actually it required 22 >> rules, also becasue some acls, like link, rename, etc. have two arguments >> (like new_path, old_path) which should be checked separately. > > Right. That's reason why you can't write like > > 1 acl writable_access path="/home/repo/\(\*\)/\*" > 1 deny task.exe!="/usr/local/bin/repo-accessor" > 1 allow It would be possible if writable_access handler internally check proper path, old_path, new_path (for single path= agument) where need. Of course I don't know implementations detail and that could be complicated if disigned unfavourable for that. > If we want generic write permission, which actions should be included into > generic write permission? Some will say only write/append/truncate should be, > some others will say write/append/truncate/create should be, yet some others > will say write/append/truncate/create/link/rename should be, and ... Yes people may think differently. But every person understand concept of read-only directory or ro mount. So to simplify understanding generic writable_access operation could implement all restrictions to implement usual read-only mount/dir. (Btw, you can add 'operation' variable with name or current operation to exclude some operation from generic one in its ruleset.) > If we simplify the granularity up to read/write/execute (e.g. DAC), we lose > the > benefit of fine grained acl. I don't say you should remove existing operations. Just to add also some generic ones to simplify maintaining and understanding for people. >> I think I covered all operations that can modify files, excluding all that >> read only. > > This is different from my expected usage. I don't understand, what is different from expected use? I want to make some directory globally read only except for its accessor software. I think this is useful in general and also useful insecurity sense. For example to protect backups from accidental/intentional modifications. It is security for backups integrity. > However, as one of CaitSith's advantages compared to TOMOYO/AKARI, you don't > have to treat all actions equally because you can choose conditions to check > and conditions to allow/deny independently. Please see Chapter 4 in > http://events.linuxfoundation.org/images/stories/pdf/lcna_co2012_handa.pdf for > examples. For example, you can define rules for write/append/truncate (actions > which may change the content of file) for per-a-pathname basis I understand that flexibility, and it's great. Thanks. >> 2. I wonder why operations like touch file (acl create) report ENOENT >> instead >> of EPERM (which would be logical). ENOENT is confusing. > > This is because /bin/touch ignores failure of open(O_CREAT) but reports > failure > of utime(). Ah, thanks for explanation! * I solved my generalisation problem myself using m4 macro processor. (I show details in case if it's useful for someone too.) I make config.m4 with such text at beginning: ------------------ divert(`-1') changequote([,]) # foreach macro from /usr/doc/m4-1.4.16/examples/foreach.m4 define([foreach], [pushdef([$1])_foreach($@)popdef([$1])]) define([_arg1], [$1]) define([_foreach], [ifelse([$2], [()], [], [define([$1], _arg1$2)$3[]$0([$1], (shift$2), [$3])])]) # generic_acl(prio, deny, (write, append, ...), path=..., [rules]) define([generic_acl], [dnl foreach(op, $3, [ $1 acl op $4 audit 1 [$5] 11111 $2])dnl ]) # deny_writable(prio, path, [common rules]) define([deny_writable], [dnl generic_acl($1, deny, (write, append, create, unlink, mkdir, rmdir, mkfifo, mksock, truncate, symlink, mkblock, mkchar, chmod, chown, chgrp, ioctl), [path=$2], [$3])dnl generic_acl($1, deny, (link, rename), [old_path=$2], [$3])dnl generic_acl($1, deny, (link, rename), [new_path=$2], [$3])dnl generic_acl($1, deny, (mount), [source=$2], [$3])dnl generic_acl($1, deny, (mount), [target=$2], [$3])dnl ]) divert[]dnl ... usual rules and headers excluded... string_group RSYNCS /home/backup/\(\*\)/\* deny_writable(7, @RSYNCS, [1 allow path="/usr/bin/rsync"]) * This example rule will instantiate 20 acls with proper path=, old_path=, etc, checks Every rule will have this line: 1 allow path="/usr/bin/rsync" And every rule will finish with 11111 deny. For example two first acls to get the idea of output: 7 acl write path=@RSYNCS audit 1 1 allow path="/usr/bin/rsync" 11111 deny 7 acl append path=@RSYNCS audit 1 1 allow path="/usr/bin/rsync" 11111 deny * Another example: generic_acl(2, deny, (write, append), task.uid=224, [ 1 allow path="/home/radio/shoutcast/sc_serv.log" 1 allow path="/home/radio/transcast/nohup.out" 1 allow path="/home/radio/transcast/sc_trans.log" 1 allow path="/home/radio/nohup.out" 1 allow path="/dev/null" 1 allow path="/dev/tty" ]) Thish rule will make two blocks of acl text each ending with 1111 deny for acl write and acl append. Acl entry check is task.uid=224 And all quoted in [ ] rules will be duplicated for each acl. Example output: 2 acl write task.uid=224 audit 1 1 allow path="/home/radio/shoutcast/sc_serv.log" 1 allow path="/home/radio/transcast/nohup.out" 1 allow path="/home/radio/transcast/sc_trans.log" 1 allow path="/home/radio/nohup.out" 1 allow path="/dev/null" 1 allow path="/dev/tty" 11111 deny 2 acl append task.uid=224 audit 1 1 allow path="/home/radio/shoutcast/sc_serv.log" 1 allow path="/home/radio/transcast/nohup.out" 1 allow path="/home/radio/transcast/sc_trans.log" 1 allow path="/home/radio/nohup.out" 1 allow path="/dev/null" 1 allow path="/dev/tty" 11111 deny * Third usage example: generic_acl(6, allow, (rename, write, create, append), task.domain="/usr/sbin/httpd", [ 11 deny new_path="/\(\*\)/\*.php\@" 11 deny new_path="/\(\*\)/.htaccess" ]) generic_acl(6, deny, (link, symlink), task.domain="/usr/sbin/httpd", []) Then I can load my config with: # m4 config.m4 | /usr/sbin/caitsith-loadpolicy Best regards, _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
