This is the "simple GUI for learning mode" part. Radoslaw Szkodzinski wrote: > > I tried to let /usr/sbin/ccs-queryd search a database and reply if $retry > > is 0 > > and let /usr/sbin/ccs-queryd ask the user what to do if $retry is not 0. > > But I > > haven't implemented it yet and therefore some dead code exists in queryd.c . > > You can just ignore it. > > In fact, I want to implement exactly this, but a bit more involved. > > Client uses a proposed ccs-ask-daemon, which connects to ccs-queryd > (with TLS authentication), sending the uid. ccs-queryd then sends all requests > that are marked as "ask about it" and concern a process owned by that uid > to the socket of ccs-ask-daemon. > So, you want to allow each user to judge only that user's events rather than allowing administrator to judge all user's events.
Unlimitedly allowing each user to judge is dangerous. But allowing each users to judge simple unknown cases as you mentioned would be fine. > 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? /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. Although it is a bit slower than using no_ask_permission, such event should not happen so frequently. 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 ) > 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. This is for performance reason and for avoiding flood of warning messages by implicit directory searching such as shell's completion. > 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 > allow_execute /usr/lib/firefox/plugin-container > ask_permission > > <kernel> /usr/lib/firefox/firefox-bin /usr/lib/firefox/plugin-container > allow_stat /store/downloads > allow_write /store/downloads > allow_execute flash > allow_execute java > ... > ask_permission > > <kernel> /uid:1234 /usr/lib/firefox/firefox-bin > allow_write /home/1234/downloads > allow_read /home/1234/downloads > allow_chmod 0770 /home/1234/downloads > # to allow overwriting > allow_rename /home/1234/downloads/* /home/1234/downloads/* > ask_permission > ask_permission makes sense for only enforcing mode. If not enforcing mode, requests are granted without sending to /proc/ccs/query interface. 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 . Regards. _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
