lkml.org 
[lkml]   [2009]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Dynamic port labeling V2
From
Date
On Fri, 2009-12-04 at 11:03 -0500, Joshua Brindle wrote:
> Paul Nuzzi wrote:
> > 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?
> >
>
> Maybe not, and it isn't like labeling filesystems is atomic so maybe I'm
> out in left field here.
>
> >> 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.
> >
>
> I actually was thinking about resizing a range. You just put the system
> in a strange state by having to remove alot of labels and then readd
> them. It seems most reliable to add the entire set of portcons every
> time (using some file on disk and a text parser to parse them in to an
> ocontext like struct then feeding it in), that way the ordering is
> always exactly like it is in the file and there is a persistent file on
> disk that can be loaded at policy load time.
>
> Users could literally do a setportcon -e to pop up an editor with all
> the portcons and reorder, modify, re-range, etc and it would all take
> effect at once.
>
> I don't know though, I may be overthinking this. Right now isn't ideal,
> portcons have to be stored in a libsemanage "database" and they get
> added to the policydb at policy build time. You could generate out a
> portcon file that sits next to the policy.24 and gets fed in at load
> time but making modifications to that and keeping them in sync would be
> a pain, unless libsemanage made the change and regenerated the file (it
> would be cheaper than rebuilding the entire policy) but that would also
> mean you'd have to modify libsemanage which I typically don't wish on
> anyone.
>

Sounds like your idea would present some a few problems. To implement
this functionality user-space would have to take out a policy lock in
the kernel for an indefinite amount of time. That brings up some issues
on scalability. Typically atomic operations are small and fast. This
also sounds like a toolchain issue. The proposed functionality can be
done in the front end of semanage or setportcon.

> I guess one issue I'm having is that in SELinux there are about 3 ways
> to do any 1 think in the typical case (sometimes there are 5 or more).
> And this adds a completely orthogonal and not integrated with the rest
> way of changing port labels, which isn't ideal. We already have trouble
> telling people how to choose one over the other in many cases.
>
> >> 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?
> >
>
> Sort of. In some cases you can echo numbers in like booleans and enforce
> and others you can't like load, all the compute functions, etc. We don't
> have to do text parsing yet and that adds a bunch of stuff to the kernel
> that isn't completely necessary. I'll defer to the kernel guys on this
> one though, since it isn't my area of expertise.
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.



\
 
 \ /
  Last update: 2009-12-07 18:35    [W:0.066 / U:17.140 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site