MLS and network

MLS and network

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Hello,

I've struck an interesting issue on stock fedora12. When you install the
MLS policy and then newrole yourself to s1 (or anything higher than s0),
you can still connect to the 'net (for example, ftp somewhere). I've
checked that the kernel is in enforcing mode.

This clearly violates the intent of MLS, as you could easily leak
confidential files this way. The question is which part is buggy? I've
looked briefly into the sources of the reference policy and it seems
that the necessary infrastructure is there: ports are labeled as s0, mls
constraints are in place and the domains of user processes do not have
mls exempts. That leaves things in a couple of options:

1) there is a bug in selinux or this feature is unsupported
2) fedora applies some patches to the policy which defeat the proper
   functioning
3) i have missed something

Any ideas?

Michal Svoboda


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MLS and network

[Stephen Smalley]

On Thu, 2010-02-04 at 18:49 +0100, Michal Svoboda wrote:
> Hello,
> 
> I've struck an interesting issue on stock fedora12. When you install the
> MLS policy and then newrole yourself to s1 (or anything higher than s0),
> you can still connect to the 'net (for example, ftp somewhere). I've
> checked that the kernel is in enforcing mode.
> 
> This clearly violates the intent of MLS, as you could easily leak
> confidential files this way. The question is which part is buggy? I've
> looked briefly into the sources of the reference policy and it seems
> that the necessary infrastructure is there: ports are labeled as s0, mls
> constraints are in place and the domains of user processes do not have
> mls exempts. That leaves things in a couple of options:
> 
> 1) there is a bug in selinux or this feature is unsupported
> 2) fedora applies some patches to the policy which defeat the proper
>    functioning
> 3) i have missed something
> 
> Any ideas?

If you want network enforcement, you need to configure labeled
networking - that isn't enabled by default.

http://marc.info/?t=126299792600001&r=1&w=2
http://marc.info/?t=126347828800001&r=1&w=2
http://paulmoore.livejournal.com/5536.html
-- 
Stephen Smalley
National Security Agency


--
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.

Re: MLS and network

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Stephen Smalley wrote:
> If you want network enforcement, you need to configure labeled
> networking - that isn't enabled by default.

Thanks. I have two more questions. First, why does MLS require this, but
for TE it is sufficient to have labeled ports? And second, I have
managed to label my network to s0, but still, if I try to connect as s1
user, the outbound connection gets through, only the response (ie.
syn/ack) is denied. This still violates BLP; is this a matter of how the
refpolicy is set up?

Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MLS and network

[Stephen Smalley]

On Fri, 2010-02-05 at 06:19 +0100, Michal Svoboda wrote:
> Stephen Smalley wrote:
> > If you want network enforcement, you need to configure labeled
> > networking - that isn't enabled by default.
> 
> Thanks. I have two more questions. First, why does MLS require this, but
> for TE it is sufficient to have labeled ports? And second, I have
> managed to label my network to s0, but still, if I try to connect as s1
> user, the outbound connection gets through, only the response (ie.
> syn/ack) is denied. This still violates BLP; is this a matter of how the
> refpolicy is set up?

(cc'd the labeled networking maintainer)

1) Regardless of security policy model (TE or MLS), the newer networking
checks (peer send/recv, netif egress/ingress, node recvfrom/sendto) were
made conditional on configuration of labeled networking to minimize
performance overhead and ensure backward compatibility for users who
have no interest in network enforcement.  MLS is concerned with
information flow among levels, and is thus concerned about the peer
relationships, which can only be known if using labeled networking.  The
port-based checks (e.g. name_bind, name_connect) are not relevant to MLS
and there are no MLS constraints written on them.

2) Can you provide more details about your configuration and your test
case (e.g. your exact netlabel configuration, the policy package you are
using, the context in which your process runs)?  If you have enabled
labeled networking and have labeled your network interface as
s0/SystemLow, then I would expect that you would trigger the following
constraint on outbound traffic:
mlsconstrain { netif } { egress }
        ((( l1 dom l2 ) and ( l1 domby h2 )) or
         ( t1 == mlsnetoutbound ));
which in English says "Only allow netif egress permission if the peer's
low level dominates the netif's low level and the peer's high level is
dominated by the netif's high level i.e. the peer's range is contained
by the netif's range", and thus egress permission would be removed from
the allowed vector if the process was running at s1 and sending outbound
traffic on a netif that was only labeled s0.

Paul, am I missing anything above?

If you build libselinux from source and install the utils (mostly
omitted from the Fedora package), you'll find a utility called
compute_av that you can use to query the actively loaded policy, e.g.
compute_av staff_u:staff_r:staff_t:s1 system_u:object_r:netif_t:s0 netif


-- 
Stephen Smalley
National Security Agency


--
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.

Re: MLS and network

[Stephen Smalley]

On Fri, 2010-02-05 at 08:54 -0500, Stephen Smalley wrote:
> On Fri, 2010-02-05 at 06:19 +0100, Michal Svoboda wrote:
> > Stephen Smalley wrote:
> > > If you want network enforcement, you need to configure labeled
> > > networking - that isn't enabled by default.
> > 
> > Thanks. I have two more questions. First, why does MLS require this, but
> > for TE it is sufficient to have labeled ports? And second, I have
> > managed to label my network to s0, but still, if I try to connect as s1
> > user, the outbound connection gets through, only the response (ie.
> > syn/ack) is denied. This still violates BLP; is this a matter of how the
> > refpolicy is set up?
> 
> (cc'd the labeled networking maintainer)
> 
> 1) Regardless of security policy model (TE or MLS), the newer networking
> checks (peer send/recv, netif egress/ingress, node recvfrom/sendto) were
> made conditional on configuration of labeled networking to minimize
> performance overhead and ensure backward compatibility for users who
> have no interest in network enforcement.  MLS is concerned with
> information flow among levels, and is thus concerned about the peer
> relationships, which can only be known if using labeled networking.  The
> port-based checks (e.g. name_bind, name_connect) are not relevant to MLS
> and there are no MLS constraints written on them.
> 
> 2) Can you provide more details about your configuration and your test
> case (e.g. your exact netlabel configuration, the policy package you are
> using, the context in which your process runs)?  If you have enabled
> labeled networking and have labeled your network interface as
> s0/SystemLow, then I would expect that you would trigger the following
> constraint on outbound traffic:
> mlsconstrain { netif } { egress }
>         ((( l1 dom l2 ) and ( l1 domby h2 )) or
>          ( t1 == mlsnetoutbound ));
> which in English says "Only allow netif egress permission if the peer's
> low level dominates the netif's low level and the peer's high level is

Sorry, s/peer's high level/peer's low level/g above.  The peer's low
level aka its current level is used in both clauses of the constraint as
that reflects its active level rather than its max clearance.
Regardless, as s1 is not dominated by s0, the first part should evaluate
to false so unless the domain happens to have the mlsnetoutbound type
attribute, the entire statement should evaluate to false and thus egress
permission should be removed from the allowed vector.

> dominated by the netif's high level i.e. the peer's range is contained
> by the netif's range", and thus egress permission would be removed from
> the allowed vector if the process was running at s1 and sending outbound
> traffic on a netif that was only labeled s0.
> 
> Paul, am I missing anything above?
> 
> If you build libselinux from source and install the utils (mostly
> omitted from the Fedora package), you'll find a utility called
> compute_av that you can use to query the actively loaded policy, e.g.
> compute_av staff_u:staff_r:staff_t:s1 system_u:object_r:netif_t:s0 netif
> 
> 
-- 
Stephen Smalley
National Security Agency


--
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.

Re: MLS and network

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

Stephen Smalley wrote:
> The port-based checks (e.g. name_bind, name_connect) are not relevant
> to MLS and there are no MLS constraints written on them.

I see. In the refpolicy they say that name_bind/name_connect have no
MLS restrictions. But they place restrictions on tcp_socket write and
read, shouldn't those kick in?

BTW, what's the difference between connect and name_connect?

> 2) Can you provide more details about your configuration and your test
> case (e.g. your exact netlabel configuration, the policy package you are
> using, the context in which your process runs)?

Fedora 12 with latest updates; mls policy package. Base package
description says:
Based off of reference policy: Checked out revision  2.20090730

Context is user_u:user_r:user_t:s1

I did something like 
netlabelctl unlbl add default address:0.0.0.0/0 \
	label:system_u:object_r:netlabel_peer_t:s0

I could see the packets on the outgoing interface.

Michal Svoboda


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MLS and network

[Stephen Smalley]

On Fri, 2010-02-05 at 17:07 +0100, Michal Svoboda wrote:
> Stephen Smalley wrote:
> > The port-based checks (e.g. name_bind, name_connect) are not relevant
> > to MLS and there are no MLS constraints written on them.
> 
> I see. In the refpolicy they say that name_bind/name_connect have no
> MLS restrictions. But they place restrictions on tcp_socket write and
> read, shouldn't those kick in?
> 
> BTW, what's the difference between connect and name_connect?

tcp_socket write, read, and connect are checks between the process
security context and the (local) socket security context.  name_connect
is between the process' context and the port context.  None of those are
per-packet checks.

> > 2) Can you provide more details about your configuration and your test
> > case (e.g. your exact netlabel configuration, the policy package you are
> > using, the context in which your process runs)?
> 
> Fedora 12 with latest updates; mls policy package. Base package
> description says:
> Based off of reference policy: Checked out revision  2.20090730
> 
> Context is user_u:user_r:user_t:s1
> 
> I did something like 
> netlabelctl unlbl add default address:0.0.0.0/0 \
> 	label:system_u:object_r:netlabel_peer_t:s0
> 
> I could see the packets on the outgoing interface.

Hmm...running that netlabelctl command was sufficient to kill my ssh
connection to my box even running targeted policy, as the requisite
permissions weren't allowed by the default policy.
$ /sbin/ausearch -m AVC -ts recent -i | audit2allow
allow netlabel_peer_t netif_t:netif ingress;
allow netlabel_peer_t node_t:node recvfrom;

egress permission was allowed, but I'd expect it to get denied by the
MLS constraint in your case.

At the risk of flooding your audit log, you might add the following
policy module to see all grantings of egress permission:

$ cat auditnetif.te
policy_module(auditnetif, 1.0)

require {
	attribute domain, netif_type;
}

auditallow domain netif_type:netif egress;

$ make -f /usr/share/selinux/devel/Makefile auditnetif.pp
$ sudo semodule -i auditnetif.pp

If you don't see avc:  granted messages in /var/log/messages
or /var/log/audit/audit.log, then it isn't performing the check at all.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: MLS and network

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

Stephen Smalley wrote:
> tcp_socket write, read, and connect are checks between the process
> security context and the (local) socket security context.
> name_connect is between the process' context and the port context.
> None of those are per-packet checks.

OK, just to be sure I understand: the local socket's context is copied
from its owning process?

> At the risk of flooding your audit log, you might add the following
> policy module to see all grantings of egress permission:

No problem, it's a VM, we can do anything. 

type=USER_ROLE_CHANGE msg=audit(1265396934.824:46): user pid=1061
uid=500 auid=500 ses=3 subj=user_u:user_r:newrole_t:s0-s1 msg='newrole:
old-context=user_u:user_r:user_t:s0-s1
new-context=user_u:user_r:user_t:s1-s1: exe="/usr/bin/newrole"
hostname=? addr=? terminal=/dev/tty2 res=success'

type=AVC msg=audit(1265396951.168:47): avc:  granted  { egress } for
pid=1088 comm="ftp" saddr=10.0.2.15 src=53060 daddr=147.32.127.222
dest=21 netif=eth0 scontext=user_u:user_r:user_t:s1
tcontext=system_u:object_r:netif_t:s0-s15:c0.c1023 tclass=netif

type=AVC msg=audit(1265396951.171:48): avc:  denied  { ingress } for
saddr=147.32.127.222 src=21 daddr=10.0.2.15 dest=53060 netif=eth0
scontext=system_u:object_r:netlabel_peer_t:s0
tcontext=system_u:object_r:netif_t:s0-s15:c0.c1023 tclass=netif

I'm kinda puzzled as of what's going on. For the egress operation the
user process is writing to the interface, but that has s0-s15. So maybe
I need to semanage the interface? But why is the default so wide, how
can I semanage all interfaces? I can't see a _default_ one...

When I do it, I get a denied egress, but only as long as I have the
netlabelctl in place. Why isn't labeling the interface sufficient? The
netlabel type is not mentioned in the egress message at all...


Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MLS and network

[Paul Moore]

On Friday 05 February 2010 08:54:46 am Stephen Smalley wrote:
> On Fri, 2010-02-05 at 06:19 +0100, Michal Svoboda wrote:
> > Stephen Smalley wrote:
> > > If you want network enforcement, you need to configure labeled
> > > networking - that isn't enabled by default.
> >
> > Thanks. I have two more questions. First, why does MLS require this, but
> > for TE it is sufficient to have labeled ports? And second, I have
> > managed to label my network to s0, but still, if I try to connect as s1
> > user, the outbound connection gets through, only the response (ie.
> > syn/ack) is denied. This still violates BLP; is this a matter of how the
> > refpolicy is set up?
> 
> (cc'd the labeled networking maintainer)
> 
> 1) Regardless of security policy model (TE or MLS), the newer networking
> checks (peer send/recv, netif egress/ingress, node recvfrom/sendto) were
> made conditional on configuration of labeled networking to minimize
> performance overhead and ensure backward compatibility for users who
> have no interest in network enforcement.

...

> Paul, am I missing anything above?

You explained it pretty well.  The only thing I might add (I was just asked 
about this yesterday, so I thought I would mention it again) is that while we 
have a peer:recv permission we don't have a peer:send permission.  Why?  Well, 
the peer:recv permission is present to allow us to control the level of the 
peer traffic a given socket is allowed to receive, i.e. a socket created at s0 
can not receive s1 labeled traffic.  If you flip this around for the send 
side, i.e. the mysterious peer:send permission, you would want the permission 
to control the level of the traffic an application could write to a give 
socket - which we already have through the other socket/FD access controls so 
adding a new peer:send permission would be redundant.  If you want to control 
what traffic is allowed out of a specific interface you want the netif:egress 
permission, that is what it is intended to do.

-- 
paul moore
linux @ hp

--
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.

Re: MLS and network

[Paul Moore]

On Friday 05 February 2010 11:49:50 am Stephen Smalley wrote:
> On Fri, 2010-02-05 at 17:07 +0100, Michal Svoboda wrote:
> > Stephen Smalley wrote:
> > > 2) Can you provide more details about your configuration and your test
> > > case (e.g. your exact netlabel configuration, the policy package you
> > > are using, the context in which your process runs)?
> >
> > Fedora 12 with latest updates; mls policy package. Base package
> > description says:
> > Based off of reference policy: Checked out revision  2.20090730
> >
> > Context is user_u:user_r:user_t:s1
> >
> > I did something like
> > netlabelctl unlbl add default address:0.0.0.0/0 \
> > 	label:system_u:object_r:netlabel_peer_t:s0
> >
> > I could see the packets on the outgoing interface.
> 
> Hmm...running that netlabelctl command was sufficient to kill my ssh
> connection to my box ...

Do you type everything you read on the internet into a root shell?  I always 
figured you were smarter than that :)

Kidding aside, the 'netlabelctl unlbl add|del ...' commands only effect the 
peer labeling used when a packet is not labeled via a labeling protocol, 
e.g. CIPSO or labeled IPsec.  It does not affect the labeling of outbound 
traffic in any way.  Here is an example of using it to label unlabeled 
traffic entering the system:

 * http://paulmoore.livejournal.com/1758.html

For outbound packets that originate on the local system, you don't need to 
specify a fallback peer label as we determine the packet's peer label based 
on the socket's label, which we can access at all of the egress control 
points via a back pointer in the packet itself.  It is a little more 
interesting for forwarded packets as we don't have access to the sending 
socket, in this case we derive the packet's peer label just like we do for 
incoming packets: first we look for a CIPSO or labeled IPsec peer label then 
we fall back to a fallback label if one is configured.  I really haven't 
written much about forwarding packets and manipulating the peer labels but 
you can do some really cool stuff with it if you have a little patience to 
get the configuration just right.

-- 
paul moore
linux @ hp

--
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.

Re: MLS and network

[Paul Moore]

On Friday 05 February 2010 02:28:07 pm Michal Svoboda wrote:
> Stephen Smalley wrote:
> > tcp_socket write, read, and connect are checks between the process
> > security context and the (local) socket security context.
> > name_connect is between the process' context and the port context.
> > None of those are per-packet checks.
> 
> OK, just to be sure I understand: the local socket's context is copied
> from its owning process?

Yes, unless you change it via setsockcreate(); see the libselinux API 
documentation for more information.

> > At the risk of flooding your audit log, you might add the following
> > policy module to see all grantings of egress permission:
> 
> No problem, it's a VM, we can do anything.

...

> type=AVC msg=audit(1265396951.168:47): avc:  granted  { egress } for
> pid=1088 comm="ftp" saddr=10.0.2.15 src=53060 daddr=147.32.127.222
> dest=21 netif=eth0 scontext=user_u:user_r:user_t:s1
> tcontext=system_u:object_r:netif_t:s0-s15:c0.c1023 tclass=netif

Here you have a process, labeled "...:user_t:s1", sending traffic via a 
network interface which is labeled "...:netif_t:s0-s15:c0.c1023".  Looking 
at the mlsconstrain rule, which is specified as:

	mlsconstrain { netif } { egress }
	        ((( l1 dom l2 ) and ( l1 domby h2 )) or
	         ( t1 == mlsnetoutbound ));

... it would appear that any traffic with a label "between" (not really a 
BLP term, but I think you get the idea) the effective/low and cleared/high 
labels of the network interface is allowed.  So, this appears to be working 
correctly.

> type=AVC msg=audit(1265396951.171:48): avc:  denied  { ingress } for
> saddr=147.32.127.222 src=21 daddr=10.0.2.15 dest=53060 netif=eth0
> scontext=system_u:object_r:netlabel_peer_t:s0
> tcontext=system_u:object_r:netif_t:s0-s15:c0.c1023 tclass=netif

Not 100% sure about this, but I'm fairly certain this is SELinux type 
enforcement issue.  Have you tried adding some policy like the following:

	allow netlabel_peer_t netif_t:netif { ingress };

> I'm kinda puzzled as of what's going on. For the egress operation the
> user process is writing to the interface, but that has s0-s15. So maybe
> I need to semanage the interface?

I assume you want the "...:user_t:s1" traffic denied from leaving via the 
"...:netif_t:s0-s15:c0.c1023" interface?  Well you could always relabel the 
interface to operate at a single level.  The blog post below has some 
information on how to use semanage to manipulate the label assigned to 
network interfaces, note that unless explicitly specified the network 
interfaces will be labeled as you have seen ("...:netif_t:s0-s15:c0.c1023"):

 * http://paulmoore.livejournal.com/5536.html

> But why is the default so wide ...

Somebody decided to make it that way and no one has really complained.

> ... how can I semanage all interfaces?  I can't see a _default_ one...

The default setting is part of the SELinux policy using an "initial SID" and 
isn't something you probably want to modify.  I would recommend using 
semanage to set the interfaces individually.

> When I do it, I get a denied egress, but only as long as I have the
> netlabelctl in place. Why isn't labeling the interface sufficient? The
> netlabel type is not mentioned in the egress message at all...

Dynamic permission checks.  If you don't have any type of labeled networking 
configuration present the permission checks are disabled inside the kernel.  
It may seem odd right now, but trust me, this is a very good thing.

-- 
paul moore
linux @ hp

--
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.

Re: MLS and network

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

Paul Moore wrote:
> Not 100% sure about this, but I'm fairly certain this is SELinux type
> enforcement issue.  Have you tried adding some policy like the
> following:
> 
> 	allow netlabel_peer_t netif_t:netif { ingress };

Nope, but sesearch comes up empty. In other news, same denial for
s0<->s0. So, you're right.

> The default setting is part of the SELinux policy using an "initial
> SID" and isn't something you probably want to modify.  I would
> recommend using semanage to set the interfaces individually.

I don't think this is such a good idea. The rule should be "what's not
allowed, is denied". Now all interfaces that the user sticks in get
implicitly s0-s15 and, perhaps even worse, since they have to be
reconfigured from userspace, there would be a slight delay until that
happens, even if done by udev-launched script. Moreover, interfaces can
be labeled anyhow, so pre-semanaging eth0 through say eth99 is only a
partial solution, let alone clumsy.

Thus I would advocate for the default to be low.

> Dynamic permission checks.  If you don't have any type of labeled
> networking configuration present the permission checks are disabled
> inside the kernel.  It may seem odd right now, but trust me, this is a
> very good thing.

I agree, this is odd and brutally contra-intuitive. We're speaking about
egress checks (due to BLP) but we need to configure ingress labeling?
(And even of a fallthrough kind?) What's the reasoning behind this?

There's one more question, if I may. It appears to me that secmark and
netlabel, when confronted with normal (ie. non-CIPSO, etc) traffic,
provide redundant ways to label ingress packets. (Netlabel has fewer
options but it too operates on a per-packet basis.) Is this so, and if,
are there plans for unification?

Regards,
Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MLS and network

[Paul Moore]

On Sunday 07 February 2010 01:10:16 pm Michal Svoboda wrote:
> Paul Moore wrote:
> > The default setting is part of the SELinux policy using an "initial
> > SID" and isn't something you probably want to modify.  I would
> > recommend using semanage to set the interfaces individually.
> 
> I don't think this is such a good idea. The rule should be "what's not
> allowed, is denied". Now all interfaces that the user sticks in get
> implicitly s0-s15 and, perhaps even worse, since they have to be
> reconfigured from userspace, there would be a slight delay until that
> happens, even if done by udev-launched script. Moreover, interfaces can
> be labeled anyhow, so pre-semanaging eth0 through say eth99 is only a
> partial solution, let alone clumsy.

Well, keep in mind that once you label the interface via semanage, on 
subsequent reboots it takes effect before the network is brought up (it 
happens during policy load) so you don't really have to worry about any race 
conditions.  However, you do make a good point about interface naming, but I 
would suspect that anyone who is interested in running the strict/MLS 
SELinux policy is also tightly controlling physical access to the machine 
and binding interface names/configuration to the physical MAC address which 
means problems caused by new or mis-named interfaces are not a real concern.

> > Dynamic permission checks.  If you don't have any type of labeled
> > networking configuration present the permission checks are disabled
> > inside the kernel.  It may seem odd right now, but trust me, this is a
> > very good thing.
> 
> I agree, this is odd and brutally contra-intuitive. We're speaking about
> egress checks (due to BLP) but we need to configure ingress labeling?
> (And even of a fallthrough kind?) What's the reasoning behind this?

So let me get this straight ... you are very concerned about what 
information leaves your system over what physical network, but you don't 
care at all about the information coming into your system?  That seems odd 
to me.  The SELinux network access controls are dynamic and assume that 
those who wish to use them want to enforce access controls on traffic both 
leaving and entering the system.

> There's one more question, if I may. It appears to me that secmark and
> netlabel, when confronted with normal (ie. non-CIPSO, etc) traffic,
> provide redundant ways to label ingress packets. (Netlabel has fewer
> options but it too operates on a per-packet basis.) Is this so, and if,
> are there plans for unification?

This next point may sound minor, but trust me it is important: the per-
packet labels provided by secmark do not represent the same security 
attributes as the per-packet labels provided by NetLabel (or labeled IPsec 
for that matter).  The secmark labels represent the IP attributes of the 
packet, e.g. IP addresses, while the NetLabel and labeled IPsec labels, 
called network peer labels, represent the security attributes of the sender, 
e.g. apache_t.  Because these two different types of labels represent 
different packet attributes they will not be unified.  There was a _lot_ of 
discussion about this several years ago (search for "secid reconciliation" 
or similar) and the general consensus at the end was that unification would 
be a mistake.  However, we have unified/reconciled the different peer label 
controls (NetLabel and Labeled IPsec) over the years and I think that has 
worked our fairly well, at least I'm happy with it anyway :)

-- 
paul moore
linux @ hp

--
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.

Re: MLS and network

[Michal Svoboda]

[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]

Paul Moore wrote:
> Well, keep in mind that once you label the interface via semanage, on
> subsequent reboots it takes effect before the network is brought up
> (it happens during policy load) so you don't really have to worry
> about any race conditions.  However, you do make a good point about
> interface naming, but I would suspect that anyone who is interested in
> running the strict/MLS SELinux policy is also tightly controlling
> physical access to the machine and binding interface
> names/configuration to the physical MAC address which means problems
> caused by new or mis-named interfaces are not a real concern.

There are also software interfaces like tunnels and taps, and god knows
what else (you can even run a ppp interface over a ssh session). At some
point it might just be that they are all pinned down and tightly
controlled, but why have to do all this *just because* the default is
systemhigh and not *in addition to* a sane systemlow default? Isn't a
longish list of semanaged interfaces just a more volatile version of a
low default?

> So let me get this straight ... you are very concerned about what
> information leaves your system over what physical network, but you
> don't care at all about the information coming into your system?  That
> seems odd to me.  The SELinux network access controls are dynamic and
> assume that those who wish to use them want to enforce access controls
> on traffic both leaving and entering the system.

If you just want to protect confidential data in your box then strictly
speaking yes! egress traffic is everything you need to worry about (at
least network-wise).

Second, I'm not quite sure if I understand why defining a *fallback*
label is necessary to turn on the whole infrastructure. I think that
the fallback label is not that much necessary in most situations.

If I wanted to implement a MLS network then my first shot would be to
designate a separate interface for s1 traffic. Thus my eth1 would have
s1 and I wouldn't need a fallback label there.

If I wanted to use single interface for multiple levels, I could use the
CIPSO stuff to mark packets at the sender and yet again I would do
without fallback labels at the receiver. (I would assume unmarked
packets as invalid.)

Only if I wanted to use a single interface for both unmarked and marked
traffic I would need to define a fallback label.

> This next point may sound minor, but trust me it is important: the
> per- packet labels provided by secmark do not represent the same
> security attributes as the per-packet labels provided by NetLabel (or
> labeled IPsec for that matter).  The secmark labels represent the IP
> attributes of the packet, e.g. IP addresses, while the NetLabel and
> labeled IPsec labels, called network peer labels, represent the
> security attributes of the sender, e.g. apache_t.  

That's true only when the sender already fills in the netlabel info. My
point was that netlabel fallback labels can be only configured per IP
address, but secmark has the whole netfilter infrastructure behind it,
thus could provide more fine-grained fallback labeling.

Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MLS and network

[Paul Moore]

On Wednesday 10 February 2010 01:27:29 am Michal Svoboda wrote:
> Paul Moore wrote:
> > Well, keep in mind that once you label the interface via semanage, on
> > subsequent reboots it takes effect before the network is brought up
> > (it happens during policy load) so you don't really have to worry
> > about any race conditions.  However, you do make a good point about
> > interface naming, but I would suspect that anyone who is interested in
> > running the strict/MLS SELinux policy is also tightly controlling
> > physical access to the machine and binding interface
> > names/configuration to the physical MAC address which means problems
> > caused by new or mis-named interfaces are not a real concern.
> 
> There are also software interfaces like tunnels and taps, and god knows
> what else (you can even run a ppp interface over a ssh session).

Yes, but I don't understand how those are relevant to network interface 
labeling as discussed in my response to you (above).

> At some point it might just be that they are all pinned down and tightly
> controlled, but why have to do all this *just because* the default is
> systemhigh and not *in addition to* a sane systemlow default?

Controlling access to an application and controlling access to the network 
are two different access decisions in SELinux.

> Isn't a longish list of semanaged interfaces just a more volatile version
> of a low default?

I imagine it depends on your perspective.  It doesn't bother me but it is 
apparent that bothers you a great amount.

> > So let me get this straight ... you are very concerned about what
> > information leaves your system over what physical network, but you
> > don't care at all about the information coming into your system?  That
> > seems odd to me.  The SELinux network access controls are dynamic and
> > assume that those who wish to use them want to enforce access controls
> > on traffic both leaving and entering the system.
> 
> If you just want to protect confidential data in your box then strictly
> speaking yes! egress traffic is everything you need to worry about (at
> least network-wise).

To be honest with my perspective: I suspect that the number of people 
interested in an "egress only" SELinux network access control solution are 
extremely rare, so much so that I think it might be hurtful to the rest of 
the users to change things just for this one particular use case.

> Second, I'm not quite sure if I understand why defining a *fallback*
> label is necessary to turn on the whole infrastructure. I think that
> the fallback label is not that much necessary in most situations.

Okay, I'm not going to try and convince you either way, we both seem to be 
quite comfortable with our opinions.  However, just for the record you can 
active the SELinux labeled networking access controls via the following:

 * Peer Labels
   + Configure a CIPSO DOI definition via NetLabel
   + Configure a static/fallback label mapping via NetLabel
   + Configure a labeled IPsec SPD entry via labeled IPsec

 * Secmark Labels
   + Configure a iptables/netfilter rule with a SECMARK target

> If I wanted to implement a MLS network then my first shot would be to
> designate a separate interface for s1 traffic. Thus my eth1 would have
> s1 and I wouldn't need a fallback label there.

If you wanted incoming traffic to be labeled as "s1" and you weren't using a 
labeling protocol, e.g. CIPSO or labeled IPsec, you would.

> If I wanted to use single interface for multiple levels, I could use the
> CIPSO stuff to mark packets at the sender and yet again I would do
> without fallback labels at the receiver. (I would assume unmarked
> packets as invalid.)

However you would have to configure a CIPSO DOI on the SELinux system which 
would activate the network peer label access controls as stated above.

> Only if I wanted to use a single interface for both unmarked and marked
> traffic I would need to define a fallback label.

Not really, you only need the fallback peer label if you are receiving 
traffic from unlabeled hosts and you want to treat the traffic as peer 
labeled, e.g. talking to Windows hosts.

> > This next point may sound minor, but trust me it is important: the
> > per- packet labels provided by secmark do not represent the same
> > security attributes as the per-packet labels provided by NetLabel (or
> > labeled IPsec for that matter).  The secmark labels represent the IP
> > attributes of the packet, e.g. IP addresses, while the NetLabel and
> > labeled IPsec labels, called network peer labels, represent the
> > security attributes of the sender, e.g. apache_t.
> 
> That's true only when the sender already fills in the netlabel info. My
> point was that netlabel fallback labels can be only configured per IP
> address, but secmark has the whole netfilter infrastructure behind it,
> thus could provide more fine-grained fallback labeling.

You are completely ignoring the fact that the network peer and secmark 
labels are handled differently, i.e. different access controls, by SELinux.  
The fallback peer labels are not designed as a substitute or alternate for 
the secmark labels (the opposite also applies); fallback labels are designed 
as a way to apply network peer label access controls to communications with 
unlabeled hosts.

-- 
paul moore
linux @ hp

--
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.