Bug 631 - Extended shadowing control: teachers should be able to shadow students
: Extended shadowing control: teachers should be able to shadow students
Status: NEW
: ThinLinc
VSM Server
: 1.3.0
: Other Linux
: P2 Enhancement
: MediumPrio
Assigned To:
  Show dependency treegraph
Reported: 2004-06-21 10:58 by
Modified: 2017-07-04 14:30 (History)

Script that sets allowed_shadowers from a group (436 bytes, text/plain)
2010-06-09 09:48, Peter Åstrand


You need to log in before you can comment on or make changes to this bug.

------- Comment #1 From cendio 2004-11-08 14:03:12 -------
------- Comment #2 From cendio 2010-06-09 09:39:05 -------
I think the easiest way to do this is to extend allowed_shadowers so that it
supports group names using the "+" syntax, just like explicit_agentselection
------- Comment #3 From cendio 2010-06-09 09:48:12 -------
Created an attachment (id=365) [details]
Script that sets allowed_shadowers from a group
------- Comment #4 From cendio 2012-11-19 11:21:41 -------
*** Bug 98 has been marked as a duplicate of this bug. ***
------- Comment #5 From cendio 2012-11-19 11:24:21 -------
This bug description is somewhat vague. The example from Les means both
extending the configuration so that users in certain groups are allowed to
shadowing, but also restrict shadowing which users can be shadowed. Extending
allowed_shadowers with a group syntax (using "+") solves the former problem but
not the latter: Members of those groups will still be able to shadow *anyone*.
------- Comment #6 From cendio 2012-11-19 11:39:10 -------
My suggestion is that this bug is solved by dropping allowed_shadowers
altogether, and instead use "sudo": Thus, if user Alice is allowed to execute
/usr/bin/thinlinc-login as user Bob, then Alice should be allowed to shadow
Bob. There are several advantages of this approach:

* sudo already has a very extensible configuration file, using Extended
Backus-Naur Form (EBNF). 

* In many cases, sysadmins have already configured sudoers properly. In
principle, if Alice can execute thinlinc-login as Bob, she can create a TL
session as Bob anyway (with some clever hacking). 

* Our code in VSM will be small; we will just need to execute sudo to check if
Alice is allowed to shadow Bob. This can be done with either:

$ sudo -l -u Bob /usr/bin/thinlinc-login 
[sudo] password for Alice: 

This just checks permissions. Or, we can actually execute it:

$ sudo -u Bob /usr/bin/thinlinc-login 

The above 2 commands requires the password, it seems. Listing all allowed
commands with "sudo -l" does not, don't know why. VSM do have the password
available, though, so we should be able to feed it to sudo, and we already have
code for this. 

* In addition to extending the configuration to handle group shadowers as well
as a fine grained control over who to shadow, the configuration allows for
setting permissions based on other factors such as which machine you running
------- Comment #7 From cendio 2012-11-19 11:49:31 -------
(In reply to comment #6)

> The above 2 commands requires the password, it seems. Listing all allowed
> commands with "sudo -l" does not, don't know why. 

This turned out to be wrong, I was fooled by existing time stamp. The correct
test command should be:

$ sudo -lAk -u Bob /usr/bin/thinlinc-login

Then, we set SUDO_ASKPASS to a helper program.
------- Comment #8 From cendio 2012-11-20 09:39:04 -------
Created an attachment (id=459) [details]
Sudo implementation

It turns out that since vsmserver runs as root, dealing with passwords are not
necessary. This allows for a very small and neat implementation. 

$ LANG=C svn diff | diffstat
 modules/thinlinc/vsm/vsmcommon.py |   30 +++++++++++++++++++++++-------
 vsmserver.hconf                   |    4 ----
 2 files changed, 23 insertions(+), 11 deletions(-)
------- Comment #9 From cendio 2012-11-20 09:58:55 -------
(In reply to comment #8)
> Created an attachment (id=459) [details] [details]
> Sudo implementation

Some configuration examples. First, note that you can define an alias:

Cmnd_Alias TLSHADOW = /usr/bin/thinlinc-login

Then, a few examples:

* Les original request:
all = root 
students = teachers admin 
teachers = headmaster


root        ALL=(ALL)         ALL  # This is sudo default, can also be limited
to thinlinc-login
%teachers   ALL=(%students)  TLSHADOW
%admin      ALL=(%students)  TLSHADOW
%headmaster ALL=(%teachers)  TLSHADOW

* Replacing the previous "allowed_shadowers", ie users able to shadow anyone:

superuser   ALL=(ALL)        TLSHADOW

Of course there are also many possibilities with limiting shadowing to certain
machines, netgroups, SELinux roles etc. Also, there's a /etc/sudoers.d/ which
we could use for example if we want to create a web frontend.
------- Comment #10 From cendio 2016-12-15 10:48:25 -------
We'll start with the simple approach of just mapping users and groups and
hopefully that should cover most use cases.

E.g. this config:

@ALL = root 
+students = +teachers admin 
+teachers = headmaster 

This would mean that any user in the group "teachers" (or the user "admin") can
shadow any user in the group "students".