On 5 June 2016 at 19:12, Kyle Sallee <kyle.sal...@gmail.com> wrote:
> I 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?
This is what I'm trying to achieve: keep number of rules as minimal as possible.
> 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.
Not sure what you mean here.
> 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?
> 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?
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.
> 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.
I'm using OpenWrt as base, with busybox and musl, tomoyo-tools also work.
>
> On Sun, Jun 5, 2016 at 1:28 AM, Roman Yeryomin <leroi.li...@gmail.com>
> 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.
>
>
_______________________________________________
tomoyo-users-en mailing list
tomoyo-users-en@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/tomoyo-users-en
