On Thu, 2009-12-03 at 14:31 -0500, Joshua Brindle wrote:Paul Nuzzi wrote:Second version of the dynamic port labeling patch. Changed the name ofAside from the conversation Dave and Casey are having I still think this
the selinuxfs interface to portcon and changed the interface to only
allow five arguments instead of the variable four or five.
Added a mechanism to add/delete/update port labels with an interface in
the selinuxfs filesystem. This will give administrators the ability to
update port labels faster than reloading the entire policy with
semanage. The administrator will also need less privilege since they
don't have to be authorized to reload the full policy.
A listing of all port labels will be output if the file /selinux/portcon
is read. Labels could be added or deleted with the following commands
echo -n "del system_u:object_r:ssh_port_t:s0 6 22 22"> /selinux/portcon
echo -n "add system_u:object_r:telnetd_port_t:s0 6 22 22"> /selinux/portcon
isn't quite right. First, while you can atomically change a single port
label with the add command above you can't atomically change multiple
entries, which I think is completely necessary (you don't want to have
strange labeling states when changing a set of ports to a new label.
Can you think of a situation where we would need to atomically change
multiple entries? I envisioned a sys admin stopping their application
or server, relabeling the ports and then restarting them. Maybe there
is a specific case you know about that I've overlooked?
Also, if you are dealing with ranges you need to essentially pop off all
the specific ports, change the range and push all the specific ports
back on. With the current interface I don't see how that is possible at
all.
If you want to change the label on a range you can do it with the atomic
add operation. The only time you would need to pop all the ports and
push them back is resizing a range.
Also, while having a text parser in the kernel makes it easier to use
with echo I think it is alot of code in the kernel for no good reason.
There is no reason not to make a userspace tool that converts the
textual representation into a serialized struct and feed it to the
kernel. We typically tell users not to mess around in /selinux anyway,
since we have a libselinux interface to do that.
We also need to be able to get that information back out somehow, and we
need to be able to keep the on-disk policy consistent with the changes
we are making at runtime. setsebool -P does this, but it rebuilds the
policy, which you are trying to avoid. How do you make these portcon
changes persist across reboots? I don't imagine very many scenarios
where you only want to temporarily change portcons.
It seems like you'd need to manage an on-disk file of all the ports and
load them right after loading the policy (which is still racy but the
default port sid should prevent any traffic on the ports.
There is no question that a userspace tool like setsebool will have to
be written to save the modified policy. I used a text parsing interface
to stay consistent with the current selinuxfs interfaces where you can
echo numbers into files to modify functionality. Would adding a
structure ingesting write interface break consistency?