TOMOYO
ForkI would not normally respond,
however this request seems potentially similar
to my domain rules.
Domain automatic transition with program execution is disabled.
By a few domains ; various access levels are provided.
By writing to /sys/kernel/security/tomoyo/self_domain
a more restricted access domain can be selected.
However, for an embedded system, perhaps 2 domains would suffice?
Conceptually POSIX capabilities seem similar.
However, by Tomoyo rules adequate customization becomes possible.
Yet the following question seems solicited.
Could dropping some POSIX capabilities suffice?
Since I do not do that; I would not know.
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\*
In Roman Yeryomin's example the following line occurs.
path_group ALMOST_ANY_FILE /\*/\*\-mtd\?\*
At first something about that line looks odd.
But it looks okay.
More often rules contain /\{\*\}/ to match any directory depth.
When seeing /\*/ then a mistake is surmised.
But it seems adequate above.
Would
path_group ALMOST_ANY_FILE /dev/\*\-mtd\*
suffice?
Any device name which starts with mtd would be excluded.
Therefore, /dev/mtd15 and /dev/mtdr0 also would be excluded.
Do /dev/mtdr* devices become?
Should their content be hidden?
Because a device node can be accessed by any process
mitigating /bin/dd only access might not suffice?
And only if within that domain the domain rules apply.
>From bash for example:
read < /sys/kernel/security/tomoyo/self_domain; echo "$REPLY"
might be useful.
If the Tomoyo domain is added to the shell prompt
then that also can be useful.
Even if the rules are tight, by the presence of a kernel command line
parameter
Tomoyo activation could be precluded, prevented, thwarted?
That may be worth consideration.
To simply avert curious eyes, could device node deletion suffice?
To all processes, except perhaps the hotplug process,
the ability to create device nodes can be denied.
For example, by a domain almost every action
except file mkblock and file mkchar can be approved.
That consideration might be prudent.
# mknod /dev/alt-mtd0 b 90 0
and the C equivalent mknod function are easily invoked.
A hot plug implementation should be easy.
On an embedded system udev would not be used.
To write a hotplug program the following documentation may be useful.
/usr/src/linux/Documentation/networking/netlink_mmap.txt
and
https://www.kernel.org/doc/pending/hotplug.txt
However the hotplug.txt document is slightly old.
Therefore, by the kernel when hot plug events are reported
a bit more information such as MODALIAS= is provided.
Using a netlink socket for handling hot plug events may be superior.
By the traditional method any environment variables could be set
and then /sbin/hotplug could be invoked.
Therefore, if the traditional method is used
a progenitor process ID check may be prudent.
Perhaps 0 or 1 would become?
Otherwise a hot plug event could be simulated.
Since the netlink socket method was used;
how to secure a traditional method is surmised and not tested.
# ls -lah /sbin/hotplugd
-rwxr-xr-x 1 root root 7.0K May 27 16:38 /sbin/hotplugd
# file /sbin/hotplugd
/sbin/hotplugd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
4.0.0, stripped
To handle hot plug an incredibly large and complex program is not required.
If uninterested in self coding:
by https://www.busybox.net/
an excellent self decompressing embedded system tool kit is provided.
With uClibc; busybox can be statically linked.
A bootable glibc free embedded system is possible.
However, at least by me, uClibc statically linked tomoyo-tools has not been
attempted.
Good luck with the embedded system design and implementation.
On Sun, Jun 5, 2016 at 1:28 AM, Roman Yeryomin <leroi****@gmail*****>
wrote:
> Hello!
>
> I'm trying to build a minimal policy for my embedded system where all
> read/write requests to /dev/mtd* should be blocked except for several
> programs.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.osdn.me/mailman/archives/tomoyo-users-en/attachments/20160605/75c79022/attachment.html>