Different authentication with different user roles

Different authentication with different user roles

[Krzysztof Katowicz-Kowalewski]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

Hello,

I’m watching SELinux mailing list since a few months and it’s my first time here to ask a question. I haven’t found the answer for this one anywhere, so maybe you guys would help me, or maybe there’s no such thing I’ve imagined. But let’s move to the main part, I have two questions are related examples…

1) It is possible to authenticate user in different way for each of the roles he’s in?

When the user is logged in and had the role of staff_r, he would type newrole command and depending on the new role given as an argument he would be asked about different passwords in each case. The default password for the account would not allow him to be authenticated and gain higher privileges in the system.

This scenario may looks like a bit of abuse of using single account by different people who has different passwords to authenticate but in fact there might be real world examples of this situation. In example, you could switch to some kind of sandbox role without using predefined shell binary only the newrole itself. Another example when you’re logging in from untrusted source and you could consider that all of your moves are being logged - having separate passwords for different roles would give the attacker access to only part of the system, not the whole one. These examples may look a bit of naive but I’m interested mainly in the idea pointed in the question and there’re only here to illustrate the situation. 

2) Could the method of authentication and source of authentication request be used to determine the role a user should be in by default?

And in this case I've imagined it in the following way. We can also assume that the primary role for the user is staff_r.
a) If the user is logged in locally (using tty, not pty as in case of sshd remote access) he could be authorized as sysadm_r without further authentication.
b) If the user is logged in using ssh from trusted source (trusted IP address, trusted subnetwork) then he could be authorized as sysadm_r without further authentication.
c) If the user is logged in using ssh but he had used his private key rather than a passphrase for authentication then he could be authorized as sysadm_r without further authentication.

Once more, these are just examples.

As far as I’ve researched, the second scenario could be a good example of SELinux aware software and as I guest at least in b) and c) case it should be implemented directly in sshd, and then sshd could be able to decide how to handle user roles. Do you know if there’s any thing like that currently implemented? And about the first case, could PAM be used somehow to deal with the mentioned problem, or maybe some other existing authentication system? I know that SELinux is used to being Type-Based Access Control rather that Role-Based Access Control and these stories I’ve presented are just examples of RBAC but in fact there’s such thing as role in SELinux, so why not use it in this way? :)

Thanks, Krzysztof Katowicz-Kowalewski

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Different authentication with different user roles

[Sven Vermeulen]

On Fri, Jun 20, 2014 at 10:16:28PM +0200, Krzysztof Katowicz-Kowalewski wrote:
> I’m watching SELinux mailing list since a few months and it’s my first
> time here to ask a question. I haven’t found the answer for this one
> anywhere, so maybe you guys would help me, or maybe there’s no such thing
> I’ve imagined. But let’s move to the main part, I have two questions are
> related examples…
> 
> 1) It is possible to authenticate user in different way for each of the
> roles he’s in?
> 
> When the user is logged in and had the role of staff_r, he would type
> newrole command and depending on the new role given as an argument he
> would be asked about different passwords in each case. The default
> password for the account would not allow him to be authenticated and gain
> higher privileges in the system.

There's no immediate support for that, but it is technically possible. The
newrole application can be built with PAM support (and that is probably the
case for the majority of Linux distributions that support SELinux), so you
can create a PAM module that authenticates the user based on different
passwords.

> 2) Could the method of authentication and source of authentication request
> be used to determine the role a user should be in by default?
> 
> And in this case I've imagined it in the following way. We can also assume
> that the primary role for the user is staff_r.  a) If the user is logged
> in locally (using tty, not pty as in case of sshd remote access) he could
> be authorized as sysadm_r without further authentication.  b) If the user
> is logged in using ssh from trusted source (trusted IP address, trusted
> subnetwork) then he could be authorized as sysadm_r without further
> authentication.  c) If the user is logged in using ssh but he had used his
> private key rather than a passphrase for authentication then he could be
> authorized as sysadm_r without further authentication.
> 
> Once more, these are just examples.

Partially, yes.

You can have users be "logged in" in a different context based on the
security context of the process through which the user is logging in. This
is defined in the default_contexts file (or the SELinux user specific files
in the users/ subdirectory) which is located inside
/etc/selinux/mcs/contexts (substitute "mcs" with the name of your policy
store).

For instance, if you don't want logins through sshd_t to be in the sysadm_r
role immediately, remove it from the list:

system_r:sshd_t		user_r:user_t staff_r:staff_t

Users that login through SSH will have their "allowed" role list checked,
and the first role in their allowed role list that is also part of the
default_contexts listing will be used. So an administrator that is mapped to
the staff_u user (and thus has "staff_r sysadm_r" as allowed roles) would be
logged in as staff_r:staff_t and not sysadm_r:sysadm_t.

Direct logins are handled through the local_login_t, which can then support
sysadm_r direct logins if you want:

system_r:local_login_t	user_r:user_t sysadm_r:sysadm_t staff_r:staff_t

This is also where the "partially" comes from. There is no method for
changing this based on the authentication used (such as password-based or
SSH key based). You can work around it if you like, for instance by having
SSH listen on two ports (or two addresses) with a different context (sshd_t
versus sshd_keyauth_t) but that is a bit hackish and requires you to
duplicate the SSH domains.

It might be a nice idea to support sensitivity based decisions, but afaik
that isn't the case right now.

Wkr,
	Sven Vermeulen