Tetsuo Handa
from-****@I-lov*****
Sat Jun 11 16:47:36 JST 2011
Horvath Andras wrote: > I think i just understood what i need to do, please tell me if i think > it correctly. > > Recently we talked about this thing, that i want to apply rules on > processes on-the-fly too, while in the meantime prepare them their > domain to enter after their restart by adding "initialize_domain" to > exception policy. Right. > So if i apply rules on the current process by selecting pid=$PID, then i > just thought i don't have to delete anything, right? Because the domain > and its rules will be referred by Tomoyo by name, and not by pid. Right. Just imagine for editing a file using a text editor application. A file's content is referred by file object. The file object is identified by the name upon open(). The file object and the file's content remain until the process closes the file even after the file object's name is marked as deleted. You can reach the file object via /proc/$PID/fd/ directory. TOMOYO's rule is referred by domain object. The domain object is identified by the name upon execve(). The domain object and the domain's rules remain until the process leaves the domain even after the domain is marked as deleted. You can reach the domain object via "select pid=$PID" command. > So let's say, if a new process start with the same PID that belonged to > my former process, then this new process - if it's a different > binary - it won't have the same domain than the former one, right? Right. > So if i get it right, then selecting the pid only just refers to the > domain by name anyway, not by pid. So i won't have any problem leaving > the domains of these PIDs untouched. Right. Reaching a domain by PID is just like opening a file via /proc/$PID/fd/ . It will return you the domain of the PID as of the moment. > Might there be any race condition during the policy update within the > kernel? Can it happen that after i wrote my policy update list to > domain_policy, that between deleting and creating the new policy, there > is a tiny amount of time, when the particular process has full > permission and it can do anything? Yes. > Or does Tomoyo work something like applying only the differences? Or it > just creates some kind of locking mechanism while updating the rules? There is no locking mechanism. To update rules in an existing domain, please feed the diff data select $domainname $newrule1 $newrule2 delete $rule1 delete $rule2 delete $rule3 . If you know LDAP, manipulating TOMOYO's rules is similar to manipulating LDAP's entries using LDIF file. Identify the target first, then diff follows. > All in all, i came up with a much simpler idea to apply the same rules > for the running process, and its next domain too. I don't even need the > pid namespace for this. > > I list domain_policy and search through all domain names for my domain > where the end of domain name in the current policy matches. > > So let's say my domain is (what i want it to belong to later): > > <kernel> /usr/sbin/dnsmasq > > and the current dnsmasq process is for example in the following domain: > > <kernel> /sbin/init /etc/init.d/rc /usr/bin/screen /bin/bash /usr/sbin/dnsmasq > > Then i have a match for "/usr/sbin/dnsmasq" at the end, so i load my > rules for the latter domain too. I do the same search for domains with > subdomains too, only checking the matches at the end. I think what you want to do is basically sed -e 's@<kernel> /sbin/init /etc/init.d/rc /usr/bin/screen /bin/bash /usr/sbin/dnsmasq@<kernel> /usr/sbin/dnsmasq@' < /sys/kernel/security/tomoyo/domain_policy > /sys/kernel/security/tomoyo/domain_policy . Just be careful not to match similar domainnames like <kernel> /sbin/init /etc/init.d/rc /usr/bin/screen /bin/bash /usr/sbin/dnsmasq/usr/sbin/dnsmasq2 .
TOMOYO
Fork