> > This is what I'm trying to achieve: keep number of rules as minimal as > possible. > In retrospect; please disregard what I wrote concerning Tomoyo. Caitsith seems worth trying. However, a below a few other potentially useful tips were included. Although I have not tried; something about use_group might be useful; as whatever is assigned to a group could be used by multiple domains. But I haven't tried. If Linux is configured with: CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/init" then by /init or whatever runs soon after the tomoyo domain can be set by writing the domain to /sys/kernel/security/tomoyo/self_domain "<kernel> //tomoyo\n" By mere program execution the above domain can not be reached. With Tomoyo rules almost anything must be explicitly enabled, except domain transition, which can be explicitly disabled. As an exception rule keep_domain any from any Then, to manually enter a domain as a domain rule <kernel> //tomoyo task manual_domain_transition <kernel> //other And now from <kernel> //tomoyo manual domain transition to <kernel> //other is possible Keeping at least 1 profile 0 domain, no rules enforced domain, can be useful. However, allowing transition from a more restrictive domain to a less restrictive domain might not be desirable. > Conceptually POSIX capabilities seem similar. > > Not sure what you mean here. > If only someone who used them could explain. Try the capabilities section 7 manual page. man 7 capabilities By man-pages available from https://www.kernel.org/pub/linux/docs/man-pages the manual page is provided. Imagine root account omnipotence as a supreme pizza. By POSIX capabilities certain pizza toppings can be omitted. For example, to omit the mushrooms CAP_SYS_BOOT could be discarded. Then execution of reboot and kexec_load are denied. While probably not too difficult to manually set; a libcap library is provided. http://www.kernel.org//pub/linux/libs/security/linux-privs/libcap2/ http://people.redhat.com/sgrubb/libcap-ng systemd might use capabilities, but since I do not use it; who knows One of the most salient sentences of the capabilities manual page follows. "If a thread drops a capability from its permitted set, it can never reacquire that capability (unless it execve(2)s either a set-user-ID-root program, or a program whose associated file capabilities grant that capability)." A main gripe concerning security is that by the proliferation of UID owned SUID executable files a castle with many secret entrances is created. With some solid Tomoyo domain rules a process can be locked in the box and by SUID escape is not possible. However, on an embedded system perhaps many SUID executable files can be omitted or mitigated? For security enhancement Tomoyo is like a hair net. Provided nothing is unexpected mount --bind, it works. Therefore, to mitigate mount --bind careful rules regarding file mount may be useful. However, even while within a chroot all rules are checked as if the root was still the original / rootfs. For example if access to file /chroot_dir/init is logged then following chroot /chroot_dir access to file /chroot_dir/init will still be logged. That is desirable. However, for /bin /sbin /lib /etc if rules exist and if the following two commands are executed: mount --bind / /chroot_dir; chroot /chroot_dir is executed then the rules from /bin /sbin /lib /etc within /chroot_dir do not apply. For fascist rules design to blind a service a problem does not become. But for a general purpose domain which can host almost any process then some consideration might be useful. For incredibly reasonable memory consumption, by Tomoyo awesome MAC, mandatory access control, can be provided. Yet the possibility of mount --bind must be anticipated and/or mitigated. > > Therefore, a potential Tomoyo solution will be discussed. > > > > By exception policy path_groups > > for nearly each device node write access is individual provided. > > However, for read access lines such as following two lines are used. > > > > path_group firm-read /dev/\*\-mapper/\* > > path_group firm-read /dev/\*\-autofs\-btrfs-control\-dm\*\-hd\*\-kmem\-md > > \*\-sd\*\-snapshot\-zram\* > > wow... how does this (second rule) work? > is it everything in /dev/, except for > autofs > btrfs-control > dm* > hd* > kmem > md* > sd* > snapshot > zram* > > am I guessing right? > Something like that. Deciding exactly where to allow writing is easier. For any device node type new rules can be added. However, for device reading, hmmm. Certain devices probably should not be read. So some of those can be listed that way while to those not explicitly listed read permission is granted. For creating device rules /usr/src/linux/Documentation/devices.txt and the mounted devtmpfs content are useful. What was provided above was not intended to be a fantastic perfect rule, but an example of how to compromise caution and leniency. Medieval castle defense similar defense Tomoyo rules can be implemented. For example; in a medieval castle a moat, a main wall, and an inner keep could exist. Where service customized Tomoyo domains are not used; a castle approach can be used where a domain outside of central keep is used. While to the keep only; the very sensitive security matters, such as read/write access to /dev/sd* to be able to partition and initialize file systems, is delegated. So for example, a couple layers beyond the keep, in a domain used by services, the system installed file system areas are read only. If a service in that domain is compromised then root kit installation would not be possible. The easy cheesy way of accomplishing somethings similar; that other administrators have done in the past is to remount file systems or portions as read only. Of course without Tomoyo; and without a drop of CAP_SYS_ADMIN by any process those file systems portions could be remounted read/write. That makes it a bit like security through obscurity, since if the obstacle is not surmised then it is not surmounted. However, if anticipated; it is too easily circumvented. Since there is only mtdX and mtdblockX using "/\*/\*\-mtd\?\*" is ok > for me (I only wanted to exclude /proc/mtd from this match) > But after I saw your rule above I think I can improve this. > It probably goes without saying, but.... /sbin/\*\-tomoyo-\*\-reboot\-shutdown If tomoyo-editpolicy can be executed or if tomoyo-loadpolicy can be executed then domain and exception rules can be arbitrarily changed. I'm using OpenWrt as base, with busybox and musl, tomoyo-tools also work. > Not sure. OpenWrt and musl seem new. If signed modules are used then arbitrary trojaned module loading can be prevented. However, module compression ratio suffers, slightly. If the system will boot and run mostly from rootFS them within kernel zram could be useful. For CPIO file compression xz is excellent. By ordering files by type, as identified by the file command, by a few percents the compression ratio can improve. https://caitsith.osdn.jp/ http://i-love.sakura.ne.jp/tomoyo/CaitSith-en.pdf CaitSith supports a blacklisting approach. With blacklisting capability an absurd looking rule with all the \- could be avoided? Is CaitSith the next evolutionary step? Should we be changing our domain and exception rules to caitsith? Sweet work, Tetsuo Handa. Just read the follow up message regarding: "The "100 acl mount" block is for preventing attackers from disguising programs using e.g. "mount --bind" request." Nice. In the future, without an additional patch by the vanilla kernel without an additional patch will caitsith be provided? Because caitsith is external; at least for me caitsith escaped notice. OpenWrt is firewall/router niche POSIX. https://www.musl-libc.org/ Excellent, an alternate libc implementation. http://www.etalabs.net/compare_libcs.html Wow that looks sweet. And according to the gcc manual page: " -mmusl Use the musl C library. This is the default on *-*-linux-*musl* targets" Looks good. Perhaps a gcc patch will not be required. Maybe a tool chain also will not be required? Without a tool chain uClibc also can be used. However, warning messages print. Thanks for the info. How did I not notice it? I have not been paying attention. musl looks fun. Especially, for coreutils, grep, sed and other utilities that tend to be excessively used by libtool and during compilation by a faster launch greater performance can be achieved. And a statically linked /init also can be useful. The entire POSIX is linked with musl and not glibc? For any programs does a problem become? In lieu of glibc; as a complete drop in replacement uClibc does not suffice. However, for uClibc overall glibc compatibility is good. After musl is installed; support for unshared name spaces and other newer Linux fun support can be tested. Thanks again. P.S. By a custom Linux kernel config; a good bit of space can be saved. And before modules are signed; module stripping with parameter --strip-unneeded is possible. The modules load, work, and when loaded and while in file system for each module file less space is required. Also by cpio xz compression where module files are not individually compressed; a far better overall compression ratio can be achieved. Technically, after boot with otherwise idle processor cycles; by lzop individual module files could be rapidly compressed and some space on the rootFS can be reclaimed. While doing so might seem backwards at first the ISO9660 file size will be smaller, and by the boot loader the smaller compressed CPIO InitRAMFS can load faster. Good luck making an awesome embedded POSIX. If I rudely butted into conversation, please forgive. I also concur that for Roman Yeryomin's task, caitsith looks awesome. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.osdn.me/mailman/archives/tomoyo-users-en/attachments/20160606/c8da1d38/attachment.html>
TOMOYO
Fork