Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRE: SELinux Networking Enhancements
From: Venkat Yekkirala <vyekkirala_at_TrustedCS.com>
Date: Mon, 16 Oct 2006 09:31:28 -0500
But no one has comeup with a "simpler" alternative that also addresses the shortcomings of secmark.
> I Only there are no secmarks in the new design to begin with. The word is a holdover from the current secmark design.
> should be _local only_ enforcement, not peer labeling, an
Agreed. But I fail to see where having a "default" peer on a netfilter
rule/secpoint
Also, don't we deem all data on a filesystem that doesn't support individual file labeling to be at the label it's mounted at?
> a remote socket is a peer and a peer should Sure. That's also allowed in secpoint.
> Exactly the kind of stuff needed for "comprehensive" flow-control that would also accommodate forwarded traffic. And we seem to have just run away from it so far.
> You'll get a flow_out for the domain->socket->secmark->(any other Have you never gone thru multiple security check points at airports and such?
> I think we have mixup on terminology here. An "association" is traditionally used to refer to an IPSec SA and it has nothing innately to do with flow-control.
> Rather than doing a string of checks like this it should be Available.
> allow socket secmark : packet { send recv }; This is VERY NARROW in that it doesn't accommodate the forwarding case. If one were to take a broader view of things, it would be: allow packet secpoint { flow_out } where packet carries the socket's label in the socket case, and for the inbound:
allow packet secpoint { flow_in }
> allow secmark association : association { flow_out flow_in }; Can't do this. Too late in the chain to base IPSec associations based on secmark. And we don't need to. You just let the association "trasparently" chosen to correspond to the label of the packet (socket indirectly).
> allow domain association : association { sendto recvfrom }; The sendto happens "transparently". The recvfrom is redundant when you already have a packet assume the SA label, and are doing (as mentioned above as well): allow socket packet { recv }
> Not any more difficult than following a trail of context transitions and such for processes when doing policy. Perhaps even simpler.
> effectively does
AND COMPREHENSIVE.
For MLS the "default" labeling is needed and if you can't leverage it for TE then no one is forcing you to do so. You would just frame your policy accordingly where the "default" labels fail to operate like explicit peer contexts.
> (except for access
Not comprehensive as explained above.
-- 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.Received on Mon 16 Oct 2006 - 10:31:56 EDT |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |