Hello. Radoslaw Szkodzinski wrote: > Does it support mprotect writable and executable bit protection like > SELinux supposedly does? > This closes the last important hole in mainline Exec Shield > implementation with NX bit (which is in mainline). > With Tomoyo (1.7 or even maybe 2.3) one could plug this hole easily, > whitelisting only problematic applications. TOMOYO is not dealing mmap()/mprotect() because I'm not familiar with them. But I think I can add TOMOYO's hook for dealing sys_mprotect() because security_file_mprotect() is allowed to sleep. How can I implement mprotect writable and executable bit protection? I don't know how to implement it. Will you suggest me policy syntax you want to use for mprotect() (e.g. allow_capability mprotect-write-execute allow_mprotect 00555000-00570000 r-xp /path/to/file )? > (I think I've asked about the following before, but got a... not so > good an answer) > Does there exist a learning mode GUI for users? > Something as simple as asking about access permission for an > application in case of access violation, > possibly remembering the rule? > I do know about the CUI, but it's not as user-friendly as it could get. > > My idea is to use Tomoyo 1.7 for MAC, provide good base rules (some of > them already made for Tomoyo Debian) > and in simple unknown cases ask the user (otherwise denying). > Said unknown cases would mostly include listening sockets, file reads > and writes. > Is there any GUI for such a dialog available? (preferably as good as gksu) Sorry. GUI does not exist. > If not, could I get at least a link to good API documentation of the > API CUI uses? > You can see the source code of /usr/sbin/ccs-queryd at http://sourceforge.jp/projects/tomoyo/svn/view/trunk/1.7.x/ccs-tools/ccstools/ccstools.src/queryd.c?view=markup&revision=3835&root=tomoyo and example at http://tomoyo.sourceforge.jp/1.7/enforcing.html#using_interactive_mode . /proc/ccs/query (for TOMOYO 1.x) and /sys/kernel/security/tomoyo/query (for TOMOYO 2.3) are the interface for monitoring policy violation. For each policy violation event, a query message is generated. You can wait for query messages using select() and fetch them using read(). A query message consists with 4 lines. The first line is a header in "Q$serial-$retry\n" format. The rest lines are identical with access logs (i.e. /proc/ccs/reject_log ). $serial is a serial number used for identifying message. When answering a query, write a line in "A$serial=$answer\n" format. $serial is the number which you obtained by read() request. If $answer is 1, the request will be granted. If $answer is 2, the request will be rejected. If $answer is 3, the request will be retried. $retry is a retry counter which is incremented when $answer was 3. The administrator may modify policy and let the kernel retry the request by answering "A$serial=3\n". To avoid letting the kernel wait forever when the userspace application cannot respond (e.g. the user logged out without terminating /usr/sbin/ccs-queryd , operation by /usr/sbin/ccs-queryd generated another query message when it is processing one query message), timeout is set to 10 seconds. If somebody was monitoring /proc/ccs/query interface but the kernel was not able to receive any answers, the kernel will reject the request (i.e. assumes "A$serial=2\n" answer was given). To reset the timeout, answer "\n" as keepalive. By answering "\n" for each second, the kernel will continue waiting for answers. (In case /usr/sbin/ccs-queryd is blocked by some reason but it continues sending keepalive, /usr/sbin/ccs-queryd is made as a single thread/process application. It could be difficult to implement GUI applications as a single thread/process application.) /proc/ccs/domain_policy (for TOMOYO 1.x) and /sys/kernel/security/tomoyo/domain_policy (for TOMOYO 2.x) are the interface for reading/writing domain policy. Since reading all domain's policy may take long time, a shortcut is provided. To fetch only single domain's policy which the process which violated policy belongs to, write "select global-pid=$GPID\n" before start reading. $GPID is the global process ID (which is unique through all PID namespaces) which is included in the second line of a query message (like below). #2010-01-10 12:29:35# profile=3 mode=enforcing (global-pid=4561) task={ pid=4561 ppid=4557 uid=0 gid=0 euid=0 egid=0 suid=0 sgid=0 fsuid=0 fsgid=0 state[0]=0 state[1]=0 state[2]=0 type!=execute_handler } path1={ uid=0 gid=0 ino=1507379 major=8 minor=1 perm=0755 type=file } path1.parent={ uid=0 gid=0 ino=1507329 perm=0755 } exec={ realpath="/bin/sleep" argc=2 envc=6 argv[]={ "sleep" "1" } envp[]={ "TERM=xterm" "PATH=/sbin:/usr/sbin:/bin:/usr/bin" "PWD=/" "LANG=en_US.UTF-8" "SHLVL=1" "_=/bin/sleep" } } There are a few more notes on /proc/ccs/query and /usr/sbin/ccs-queryd . Any questions so far? Regards.
TOMOYO
Fork