On Tue, Sep 28, 2010 at 1:18 PM, Tetsuo Handa <[email protected]> wrote: > Sorry for late response. I'm trying to allocate per-task variables from LSM on > kernels >= 2.6.29 (security_task_alloc()/security_task_free() are gone).
Sorry, I'd have to explicitly look for that and I don't have the time for this right now. >> I think ccs-queryd doesn't have the whole ruleset, am I right? > > ccs-queryd does not have ruleset, but ccs-queryd can fetch it by reading > /proc/ccs/domain_policy . A shortcut "select global-pid=$GPID\n" allows > ccs-queryd to fetch ruleset for only specific domain. > Good enough for me, but can I push an update in a similar way? Preferably even append to a domain and not replace it whole, but that is also ok. > I don't hear that such implementations traverse up to / directory so that the > administrator can stop that process from accessing /var/log/messages if > one of upper directories does not allow reaching to /var/log/ directory. Yes, this isn't too useful. > In TOMOYO, read/execute permissions for directory is not checked. Don't really care about them. > If DAC allows stat() syscall on some file or directory, TOMOYO will allow > stat() syscall on that file or directory. But it could get the syscall itself, any security_file_stat() in there? > You don't need to specify "allow_stat" keyword for reading access flags, > xattrs, file size and so on because TOMOYO cannot prevent stat() syscall. And I would like it to. Could be used to hide some more information. Perhaps allow_read should also allow_stat to make it easier to use. >> > This is for performance reason and for avoiding flood of warning messages >> > by >> > implicit directory searching such as shell's completion. >> >> Hmm... that is a misconfiguration on part of TOMOYO's user, they >> should fix $PATH >> or... write rules to allow_stat. :) >> > As I explained above, there is no way to deny stat() syscall. Yet. :) > I couldn't understand what the question is. > "allow_transit" is checked when a domainname is written to /proc/ccs/.transit > interface. Ah, so it doesn't do what I thought it does. I'd like then a forced conditional inclusion of a group of rules. Is that possible? e.g. <kernel> /foo ... include_domain "/uid:1234 /foo" if task.uid=1234 or some other way to pick a whole set of rules based on an uid, so as to not reload the whole ruleset when some user decides to accept something forever. Looks far better than many allow_read /foo/bar/* if task.uid=1234 allow_read /bar/baz/* if task.uid=2345 ... > if you don't specify targets to ask, for all requests which > did not match allow_* are sent to /proc/ccs/query interface and > are rejected unless $answer == 1 or $answer == 3 (regardless of > profile number assigned to domains). Ahha, thanks. > > If targets are specified like > > <kernel> /foo5 > use_profile 2 > allow_execute /bin/ls > allow_read /etc/fstab > ask_execute /bin/bash > > where execute request for /bin/bash is sent to /proc/ccs/query > interface, it might make sense. That would be blacklisting approach. > > Do you want TOMOYO to support blacklisting approach? That should work already, setting mode=permissive then adding deny_*, right? But yes, I'd like that. It could also be useful to trim down wide allow_* rules with a few exceptions. Of course the blacklist rule would have to be higher priority than the one which allows the access... Better example would be: <kernel> /foo5 # permissive with query=yes use_profile 6 # and this goes to ccs-queryd, which sees profile==6 and asks. deny_execute /bin/bash Best regards, Radoslaw _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
