Post by Roman Yeryomin
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:
then by /init or whatever runs soon after
the tomoyo domain can be set
by writing the domain to
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
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
However, allowing transition from a more restrictive domain to a less
might not be desirable.
Post by Roman Yeryomin
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
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.
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.
Post by Roman Yeryomin Post by Kyle Sallee
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
wow... how does this (second rule) work?
is it everything in /dev/, except for
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
Where service customized Tomoyo domains are not used;
a castle approach can be used where a domain outside of central keep is
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
Post by Roman Yeryomin
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....
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.
CaitSith supports a blacklisting approach.
With blacklisting capability an absurd looking rule with all the \- could
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."
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.
Excellent, an alternate libc implementation.
Wow that looks sweet.
And according to the gcc manual page:
Use the musl C library. This is the default on *-*-linux-*musl*
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.
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
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.