Re: MLS login (Was: Re: newrole - adding capabilities for polyinstantiation)

[Klaus Weidner <klaus@atsec.com>]

On Thu, Oct 05, 2006 at 03:04:37PM -0400, Stephen Smalley wrote:
> On Thu, 2006-10-05 at 11:08 -0500, Klaus Weidner wrote:
> > I think the sane behaviors for MLS login would be any of the following:
> > 
> > - for local VTs or serial terminals, login at the default level,
> >   and permit using newrole to change level (or role). newrole relabels
> >   the tty device to match. Alternatively, choosing a context when
> >   logging in would be ok.
> > 
> > - when using SSH with labeled networking, the network connection has a
> >   MLS label corresponding to the sending process (ssh client), and the
> >   login session gets this MLS level if it's within the user's clearance
> >   range, otherwise the session is rejected.
> 
> Just to be clear, this behavior would only occur if running sshd under
> xinetd, right?  So that the sshd instance is run in the peer's range and
> is already bound by it?  Otherwise, the normal sshd selinux support will
> just select a default context for the user without consideration of the
> peer label.

Yes, that's the current plan.

> >  Newrole is not useful for
> >   changing levels since the input or output stream won't be permitted
> >   to communicate over the socket, but newrole can be used for launching
> >   noninteractive programs that don't need to communicate with the pty.
> 
> Not sure that will work presently without some changes to newrole.

It wouldn't be a required feature, I was just bringing it up as an
example of what would be compatible with the restrictions.

> > Maybe the easiest way to get this behavior is to ensure that relabeling
> > one end of a pty pair automatically relabels the other end too. Of
> > course, trusted apps can use MLS overrides, but sshd should not do so.
> 
> I think sshd_t gets MLS overrides in policy, like other login-like
> domains, since it can create user sessions at various levels and sets
> the pty labels accordingly.

Argh, I wasn't aware that sshd has full MLS overrides:

	TYPES:
	sshd_t (11 attributes)
		ssh_server
		domain
		can_change_process_identity
		can_change_process_role
		can_change_object_identity
		mlsfileread
		mlsfilewrite
		mlsfileupgrade
		mlsfiledowngrade
		mlsprocsetsl
		privfd

Doesn't this have even worse consequences? For example when sshd does
port forwarding, does that mean that a client can ask it to connect to
arbitrary ports using sshd's MLS overrides? Of course, the evaluated
config could disable port forwarding, but this makes it doubtful if sshd
is trustworthy in an MLS environment.

> > For the MLS levels, it shouldn't be necessary to modify sshd to support
> > the restrictions - on the contrary, the restrictions should happen
> > automatically since sshd doesn't have MLS override capabilities.
> 
> ...except I think it does.  The discussion seems a bit divorced from
> reality.

Yes, unfortunately reality seems to be deficient :-(

How about a completely different approach for the MLS system
configuration:

- restrict newrole to admins only

- create a new sshd_via_xinetd_t domain with restricted privileges that
  doesn't change contexts and doesn't have general MLS overrides, just
  whatever is necessary to make polyinstantiation work
  
- for regular user console login (or if not enforcing labeled
  networking), create multiple Linux users for each human user that share
  the same uid and home directory, and use "semanage login" to map them
  to appropriate types. So you'd have smith_secret_cat1,
  smith_unclassified and so on.

I know it's ugly, but would this be a strategy to get an LSPP/RBAC
compliant system in the near future without having to rewrite sshd,
newrole, the kernel pty drivers, or the other potentially affected areas?

Comments?

-Klaus

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