On Sun, Sep 26, 2010 at 2:18 PM, Tetsuo Handa <[email protected]> wrote: > This is the "simple GUI for learning mode" part. > <snip>
>> The other thing missing is a policy definition like an ability to enable >> or disable the prompt in the policy file, e.g. >> >> ask_permission >> no_ask_permission >> > Do you want me to implement ask_permission/no_ask_permission in the kernel? Not really necessary, unless there's no other way... But unfortunately the other way would need sending either this flag or the profile name via /proc/ccs/query. > /proc/ccs/qeury interface allows userspace applications to receive all pending > messages with $serial and to send answers out of sequence. > Therefore, it is possible to let ccs-queryd reject requests immediately > (which should be rejected without forwarding the message to corresponding > user's ccs-ask-daemon process) without waiting for answers from > ccs-ask-daemon process. Slightly faster to reject invalid access, which doesn't matter much. > Although it is a bit slower than using no_ask_permission, such event should > not > happen so frequently. Or at all, in a perfect world. > Thus, I think it is possible to let /usr/sbin/ccs-queryd > filter messages. (I can implement ask_permission/no_ask_permission in kernel. > TOMOYO had these until 1.6.1 . But to simplify profile configuration, I > removed these. > http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/README.ccs?v=linux-2.4.37.10-ccs-1.8.0-pre#L1468 > ) What is necessary is a flag to discern whether ccs-queryd should or shouldn't ask, just in the protocol. I think ccs-queryd doesn't have the whole ruleset, am I right? >> It'd be also nice to have allow_stat for listing the directories >> without allowing file read. >> > TOMOYO does not check read/execute permission for directories. TOMOYO checks > mkdir/rmdir/rename/mount/unmount/pivot_root/ioctl permissions for directories. The trick is that allow_stat is for files, not allow_stat /some/directory, but allow_stat /some/directory/*. This means you can read access flags, xattrs, file size and so on. Could be useful specifically for that firefox case of file save dialog, so you can browse directories without a flood of messages, then only the write would show you the dialog(s) asking for permission. > 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. :) >> Yes, but I'm not targetting users of emulators, but users in general, say, >> a typical Ubuntu user of Firefox, so that I could write: >> >> (in enforcing mode) >> <kernel> >> no_ask_permission # possibly default >> >> <kernel> /usr/lib/firefox/firefox-bin >> allow_read cookies >> allow_write cookies >> ... >> allow_network ... >> allow_transit /uid:1234 /usr/lib/firefox/firefox-bin if task.uid=1234 >> allow_transit /uid:777 /usr/lib/firefox/firefox-bin if task.uid=2345 One short tangential question: will it execute these after checking current domain for permissions or before? >> allow_execute /usr/lib/firefox/plugin-container >> ask_permission > > <snip> > > ask_permission makes sense for only enforcing mode. If not enforcing mode, > requests are granted without sending to /proc/ccs/query interface. But it could also be used in permissive mode for deny_*. This would mean "everything is permitted, but ask about the things I deny here". > Therefore, if ask_permission/no_ask_permission are implemented in kernel, > I think ask_permission/no_ask_permission should be specified like > > $profile-PREFERENCE::enforcing={ verbose=no penalty=0 query=yes } > > in /proc/ccs/profile . If it is possible to set the profile per domain, then it is fine. Of course, ccs-queryd has to know about the profile then and the whole ruleset too. Kernel knows these already. _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
