Serge E. Hallyn wrote:
<snip>
And how do we do "(a and b) or c" ? :)
I think this is the problem should be resolved. And this relationship may be
optimiszed to implement.
What does a, b and c refer to (obviously modules) but which ones? what
about modules built into the kernel like SELinux, capabilities, root
plug and so on? How does the user know what their symbol is? This should
be done by name, (selinux and capabilities) or backdoor, and so on.
I'm not sure what you mean by "may be optimised to implement."
On a per-module basis, one approach would be:
# modprobe stacker
# echo "(a and b) or c" > /sys/security/stacker/compose
# modprobe digsig_verif
# modprobe bsdjail
# modprobe seclvl
On a per-hook basis, I suppose you could
# modprobe stacker
# echo "default a or b or c" > /sys/security/stacker/compose
# echo "inode_permission (a and b) or c" > /sys/security/stacker/compose
# ...
# modprobe digsig_verif
# modprobe bsdjail
# modprobe seclvl
Shouldn't there just be a file for each hook instead of this awkward syntax?
echo "(selinux and capabilities) or backdoor" >
/sys/security/stacker/inode_permission
echo "selinux and capabilities" > /sys/security/stacker/default
Aside from these trivial notation changes, how would this be implemented
practically? You'd have to have an init script setting these on boot,
long after some modules may have become active and started enforcing.
This makes it not trivial to set the decisions up from the beginning,
either an initrd or compiling them into the kernel as config options
would be required.
I usually think of LSM as implementing MAC and not DAC, but I guess there's
nothing stopping you :) What do you want in additional DAC, mainly to build
your own ACL's?
I'll be interested to see your results. Are you implementing your own MAC and
RBAC systems, or starting with, say, SELinux?
SELinux is flexible enough that starting a new MAC implementation from
scracth should be really a last resort.
BTW: Can someone tell me how to parse a configure file? The example source
codes are welcome. This file can be read by kernel module.
The configure file may be:
#this is comment
hostname = xxx.xxx.xxx.xxx
#this is netmask
mask = xxx.xxx.xxx.xxx
you probably shouldn't try to put a parser in the kernel, this is
excessive overhead that can be avoided by serializing the data to a
binary file and feeding that into the kernel (see SELinux and checkpolicy).
Use of a pseudofs or a sysfs interface is strongly recommended. Reading
a file from the kernel is very strongly frowned upon. As an example of the
pseudofs approach, look to linux/security/selinux/selinuxfs.c:sel_write_load
and linux/security/selinux/ss/services.c:security_load_policy. For DTE, I
use a sysfs file and cat the policy into that file line by line.
-serge
Joshua Brindle
