Re: disablenetwork (v5) patches

[Kyle Moffett]

On Sun, Jan 17, 2010 at 13:07, Michael Stone <michael@xxxxxxxxxx> wrote:
> Kyle Moffett wrote:
>> I have some time this week to split out my SELinux policy build
>> machinery; I will pull out a standalone set of files to build the
>> policy and do some extra testing on one of my bog-standard Debian
>> boxes and then send it all out again.
>
> Questions:
>
> Â1) Your patch seems to rely on a chunk of custom policy. Can this chunk of
> Â Â policy coexist without modification with pre-existing policies like the
> Â Â ones Fedora ships?
>
> Â Â If I understand correctly, the answer is "not as it is written today", for
> Â Â a couple of reasons:

Essentially, yes, the policy that I gave is an extremely limited
system.  If you wanted to constrain your application as installed on a
standard Fedora system, that would involve getting a much more
detailed policy merged in the selinux-refpolicy project.  The plusses
are that such a policy would protect against far more complex attacks
than simple network data exposure, however the policy to protect
against such attacks is far more complex as well.

Basically, I wrote that sample policy as a completely standalone
example of how to use the SELinux machinery to enforce a limited
arbitrary set of restrictions based on your stated requirements.

There has been some partially-stalled work to create a "userspace
policy server" and "hierarchical policy", essentially a mechanism by
which a program (running under a specific type) could sub-divide
itself into additional types bounded by the constraints on the
original type.  Unfortunately I haven't had a chance to look into it
in quite a while, so things may have changed significantly.


> Â2) How can an application author test whether or not the contexts defined by
> Â Â this policy are defined in the currently loaded policy?

The standard method for adding SELinux support to an application is
pretty much the same method that you use to enhance security in the
absence of SELinux:  Divide your program into multiple executables
with discrete DAC-enforced privileges (a la postfix).

Then the SELinux policy simply places a different label on each
executable (and via a type_transition rule on the process which is
*started* from that executable).  Each label is then neatly bound by
least-privilege type-based allow rules.


> Â3) Your policy relies on defining new roles for objects, regular processes,
> Â Â and network disabled processes. This is definitely a nice reuse of SELinux
> Â Â machinery. Unfortunately, I'm not sure how, as an app author, I'm supposed
> Â Â to use it.
>
> [...code for using dyntransition...]

You can do it that way, although I would certainly suggest an
appropriate config file somewhere to specify what label the software
should attempt to transition to.  The SELinux libraries have some code
for performing dynamic transitions, although as I indicated most
processes don't use them.

Really the preferred way to take advantage of SELinux is simply to
divide the program tasks securely across multiple executables and then
use the SELinux policy to lock them down individually.


> Â4) If I understand correctly, the policy you specified actually restricts
> Â Â network access by blacklisting various socket calls by protocol stack.
> Â Â Thus, AF_UNIX socket calls are unrestricted while TCP bind() and connect()
> Â Â and UDP bind(), connect(), and sendto() are restricted.
>
> Â Â I'm uncomfortable with a design based on protocol blacklisting because I
> Â Â think that it is likely to break silently whenever someone adds a new
> Â Â protocol (e.g. SCTP) to the kernel.
>
> Â Â Presumably, though, this is fairly straightforward to fix?

Yes, it's pretty easy to change specifically which access-vectors you
restrict.  If localhost-based accesses are OK, then you could use the
netif and peer-based access controls (possibly with a couple of
optional iptables rules).  That would simply restrict your ability to
send packets out of the computer, regardless of what protocol they
use.

Alternatively there are SELinux mechanisms in recent kernels to
influence whether or not "unknown" access-vectors are allowed (IE:
Those which the kernel understands but the policy does not).

> Â5) If I understand correctly, your policy restricts all uses of sendto()
> Â Â including sendto() on previously connected UDP sockets. Unfortunately,
> Â Â this restriction is too strong: the ability to sendto() on previously
> Â Â connected sockets UDP is a design goal.
> Â Â How might we address this problem?

See above, simply restrict with network peer controls.


> Â6) Can SELinux be turned on at all on kernels which do not support POSIX
> Â Â extended attributes?

My understanding is that the kernel always supported extended
attributes, but that some filesystems may have support turned off.
You can certainly turn on SELinux on such a system, but you would be
unable to label things on a per-file basis.


> Â7) Can you point me toward any measurements on what it costs (specifically in
> Â Â terms of memory and disk usage) to add basic SELinux support plus this
> Â Â policy to an embedded kernel and OS distro which doesn't presently ship
> Â Â any SELinux-related material like, e.g., the distros for the Linksys
> Â Â WRT54G and for the XO?

I don't have such measurements offhand.  If you are shipping a
pre-built policy and do not include any of the tools needed to reload
or modify it then all you really need is an /sbin/init which can mount
/selinux and copy a binary policy file to a virtual file therein.  The
actual dev tools are rather unfortunately large and slow right now,
especially with the full reference policy.

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