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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
