Date:	Fri, 04 Dec 2009 09:30:21 -0500
From:	Paul Nuzzi <pjnuzzi@...ho.ncsc.mil>
To:	Joshua Brindle <method@...icmethod.com>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, jmorris@...ei.org,
	selinux@...ho.nsa.gov,
	"George S. Coker, II" <gscoker@...ha.ncsc.mil>,
	Eamon Walsh <ewalsh@...ho.nsa.gov>,
	Stephen Smalley <sds@...ho.nsa.gov>
Subject: Re: [PATCH] Dynamic port labeling V2

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 of
> > 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
> >
> 
> Aside from the conversation Dave and Casey are having I still think this 
> 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?

> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@...ho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists