From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore To: Joshua Brindle Subject: Re: [RFC 0/5] Static/fallback external labels for NetLabel Date: Wed, 29 Aug 2007 10:56:26 -0400 Cc: Joe Nall , Darrel Goeddel , Venkat Yekkirala , selinux@tycho.nsa.gov, James Morris , Darrel Goeddel , Stephen Smalley , kaigai@ak.jp.nec.com, Eric Paris References: <200708290821.46404.paul.moore@hp.com> <46D5822F.3010804@manicmethod.com> In-Reply-To: <46D5822F.3010804@manicmethod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200708291056.26561.paul.moore@hp.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Wednesday, August 29 2007 10:26:55 am Joshua Brindle wrote: > Paul Moore wrote: > > On Wednesday, August 29 2007 12:11:14 am Joshua Brindle wrote: > >> Because of > >> what I said above I think we should 1) not do node based fallbacks and > >> 2) not do nic alias-level fallbacks. This is the safe option (as already > >> pointed out) and minimizes trust in untrustworthy things (eg., addresses > >> coming from the network). > >> > >> OTOH it may make some peoples lives easier to allow this. It is a false > >> sense of security though so I vote for doing nic level fallbacks only > >> and if someone *really* wants to do this they can just plug several nics > >> into the same network (hopefully they'd recognize the horrible things > >> they are doing if it is explicit like that). > >> > >> It sounds like the decision is still up in the air though, does anyone > >> inherently disagree with me here? > > > > I guess every decision is technically up in the air until the > > changes/patches are included in a released kernel, however, I'm pretty > > confident that host level granularity of both fallback labels and flow > > control peer label filtering is "the right thing". > > > > I understand your point about not extending trust beyond the level of the > > physical wire, that is very easy to rationalize/understand. However, > > from a practical real-world scenario (see my home network behind a NAT > > box example, as well as others) I think there is real value in extending > > the labeling beyond the wire to the host/network level. SELinux has > > always made some allowances to facilitate adoption and ease of use, i.e. > > unconfined_t, but has been careful to make sure that these concessions > > were always at the discretion of the system administrator. Fallback > > labeling and peer flow controls are configuration options which are only > > available to the system administrator and providing host level > > granularity can be a significant benefit to a lot of people. > > concessions are fine when the ramifications are understood, unconfined_t > is pretty obvious. I tend to think host level fallback labels are pretty obvious too, at least as obvious as unconfined_t if not more so. The only way to truly understand the ramifications of unconfined_t are to actually look at the policy and examine all of the interactions between unconfined_t and all of the types/attributes defined in policy. Short circuiting this by making an assumption based on the connotative meaning of the name "unconfined" is just as dangerous, if not more so in my opinion, then host level fallbacks. Explaining the ramifications of host level fallback labels are pretty simple, here is my quick take: "Choosing to enable multiple fallback labels per interface, i.e. network or host level fallbacks, can be dangerous as it is possible for malicious computers to masquerade as other computers with a different fallback label. Only use network or host level fallback labels when you can guarantee the security of the network." > But when there are security people that believe host > based labeling buys anything then it may be an inappropriate concession. I think the key difference between the two sides here is the acceptable level or risk, or the level of assurance. From what I gather, Joe and the TCS guys are deploying systems in installations where they are able to put a fair amount of trust in the network such that host level fallback labels do not introduce an unacceptable amount of risk. Your argument assumes a network with no trust where host level fallback labels present a very unacceptable risk. Both arguments are correct, the question is what level of functionality do we want to provide? > I mean, if I can get on your network and in a matter of seconds take > over both your IP and MAC address it isn't good. Worse, I could use > something like ettercap and MiM you without you even knowing (and even > inject data into the stream). Yep, I think we're all familiar with ARP cache poisoning and all the other wonderful things you can do the network. > The last email from Joe shows that even security centric people are fine > with this situation in a 'medium assurance' environment, if medium > assurance means trivially bypassable please count me out. A single > shared network is in no way medium assurance IMO, there is no inherent > security when you are on a single network (save for fancy switches that > do mac filtering and ip locking per port, how many people actually use > those features though). I'm making this argument up a bit as I go, so bear with me ... You essentially define a network by the machines connected to it, which means that if you can control the machines on that network then you effectively control the network. Joe is arguing the case for installations where he does control all of the machines on the network. > One interesting thing that just occurred to me is vlans. I'm not sure > how vlans are implemented on Linux (do they get their own interface > names?) but they are much better than the alternative which lets anyone > do anything on a single network. Like everything else I think this depends on the configuration. If you have multiple vlans on a single wire and unknown machines on that wire than vlan separation is no different from IP address separation. -- paul moore linux security @ 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.