RE: Denials from newest kernel

["Christopher J. PeBenito" <cpebenito@tresys.com>]

On Tue, 2006-10-10 at 10:42 -0400, Venkat Yekkirala wrote:
> > I don't think this is a desired behavior for a couple reasons.  First,
> > this means that every domain that has access to a specific packet, for
> > example, http_client_packet_t, but not to client_packet_t, 
> > will have to
> > dontaudit the client_packet_t access.  Thats a lot of 
> 
> But this is a problem of our own making in the policy. If we
> jump into a unique chain for a label (or a set of labels all
> fine-grained to the same "grade", and hence are non-conflicting)
> then we shouldn't see this. Please refer to the links I mentioned in
> my response to Joshua.
> 
> > dontauditing, and
> > also it will cover up legitimate denials on client_packet_t.  Second,
> 
> It won't if you defined the catch-all security point only for the
> real catch-all cases.

On both of the above two points, you're making my point.  You're
applying to constraints to the chaining of iptables rules, making
secmark work differently than the remainder of netfilter.

> > this will cause permissive to have a different behavior than 
> > enforcing.
> > This makes development in permissive more difficult, since you'll get
> > spurious denials that you wouldn't get in enforcing.

You didn't respond to this, and it is an important point.

> > > > (PeBenito changed the netmsg initial sid to no_extlabel_t, he 
> > > > didn't like network_t I guess).
> > > 
> > > This is scary to my eyes at least. I had already laid out the
> > > intended usage of these controls in terms of peer "domains" as
> > > opposed to "packet types".
> > 
> > The refpolicy interfaces should be able to make this abstraction.
> > Network_t wasn't clear in my opinion, since you only needed 
> > that access
> > for non labeled networking.
> 
> Nope, all of the following need to be able to flow_out of this pipe
> that represents the network.
> 
> 1. All the local domains that need to access the network directly
>    without flowing thru any "fine-grained" security points.
> 
> 2. All fine-grained security point domains assumed by packets that
>    are flowing out of these security points. This check should have
>    been avoidable, but is not due to implementation constraints.

I don't understand, it seems as though you're saying that all network
traffic will hit a network_t flow out check, regardless of whether it is
labeled networking or non-labeled networking.  Can you illustrate with a
couple allow rule examples?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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