Bugzilla – Bug 631
Extended shadowing control: teachers should be able to shadow students
Last modified: 2018-06-18 09:35:45
You need to
before you can comment on or make changes to this bug.
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
Created an attachment (id=365) [details]
Script that sets allowed_shadowers from a group
*** Bug 98 has been marked as a duplicate of this bug. ***
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*.
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
THINLINC-LOGIN: HELLO 4.0.0
THINLINC-LOGIN: CONNECTED MASTER
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
(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.
Created an attachment (id=459) [details]
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(-)
(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
%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.
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".
Another idea is to allow configuration such that anyone could shadow anyone
with a "*" or to implement wildcard matching.
(In reply to comment #14)
> Hello Samuel, does this issue fixed already? Or any source? Thanks
No, it's not fixed.