IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 11 June 2019   (all times are UTC)

00:26alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
01:22lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br)
02:02vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
02:19ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Ping timeout: 244 seconds)
04:07quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4)
04:10quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
04:11lucascastro has left IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br, Remote host closed the connection)
04:12lucascastro has joined IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br)
04:25alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:03alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 244 seconds)
05:19kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60)
05:20lucas_ has joined IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br)
05:20lucascastro has left IRC (lucascastro!~lucascast@177-185-139-187.isotelco.net.br, Read error: Connection reset by peer)
05:31gdi2k__ has joined IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
05:33gdi2k has joined IRC (gdi2k!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
05:33gdi2k_ has left IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 248 seconds)
05:40lucas_ has left IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br, Ping timeout: 245 seconds)
05:45gdi2k__ has left IRC (gdi2k__!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Quit: Leaving)
05:59gdi2k_ has joined IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com)
05:59gdi2k has left IRC (gdi2k!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Ping timeout: 248 seconds)
06:00stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
06:03ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:07woernie has joined IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de)
07:08alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:19
<alkisg>
Yey yey yey! We can use pam_exec for ssh authentication! No need for libpam_sshauth or anything! And it's even preinstalled, so we can use it in live CDs too!
07:20
That means that there are no obstacles anymore; ltsp19 should be ready in September, without security concerns in the default installation
07:24
I thought that pam_exec would only be able to run a script, but it can return success/failure too, and it works fine with DMs, and it can even show stdout messages of our script (e.g. invalid password)
07:37
Hmm this might be useful for non-LTSP installations as well; `apt install ltsp-sshauth; ltsp-sshauth server 1001 60000` ==>
07:37
WARNING: do you really want to fetch all user accounts with uids=1001..60000 from the server, and add them locally, and authenticate them via ssh from now on (y/n)?
07:37
WARNING: additionally, do you want to have their /home/username mounted via SSHFS on login (y/n)?
07:43statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
07:45
<alkisg>
To make DMs and accountservice behave as usual, when a user is added on the server, the sysadmin will need to run a command (e.g. ltsp initrd) to propagate the new passwd/group to clients; but no action will be needed for changed passwords; small price to pay for avoiding ldap/kerberos/nfs4 :)
08:57
<gdi2k_>
morning Alkis
08:57
Your SOCKS solution is working great :)
08:57
we would like to deploy it to our other site too if possible
09:00
<alkisg>
Heya Graham, let's go private
09:06GodFather has left IRC (GodFather!~rcc@143.59.184.72, Ping timeout: 248 seconds)
10:55gdi2k__ has joined IRC (gdi2k__!~gdi2k@217.33.65.221)
11:07GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
11:09gdi2k__ has left IRC (gdi2k__!~gdi2k@217.33.65.221, Remote host closed the connection)
11:28woernie has left IRC (woernie!~werner@p578bb7b6.dip0.t-ipconnect.de, Remote host closed the connection)
11:36gdi2k has joined IRC (gdi2k!~gdi2k@217.33.65.221)
11:51Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:06stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 258 seconds)
12:09GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 245 seconds)
12:22gdi2k has left IRC (gdi2k!~gdi2k@217.33.65.221, Ping timeout: 244 seconds)
12:31gdi2k_ has left IRC (gdi2k_!~gdi2k@host86-185-211-68.range86-185.btcentralplus.com, Remote host closed the connection)
12:46woernie has joined IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de)
12:50ogra_ has joined IRC (ogra_!~ogra@216.113.24.68)
12:51ogra_ has left IRC (ogra_!~ogra@216.113.24.68)
13:38gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
13:45ogra has joined IRC (ogra!~ogra@ubuntu/member/ogra)
13:46woernie has left IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de, Remote host closed the connection)
14:01stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
14:01gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Read error: Connection reset by peer)
14:04gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
14:09gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Read error: Connection reset by peer)
14:10GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
14:22lucas_ has joined IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br)
14:25alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds)
14:34alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
14:48alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer)
14:58alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
15:03lucas_ has left IRC (lucas_!~lucascast@177-185-139-187.isotelco.net.br, Quit: Leaving)
15:15gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
15:37gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Quit: Leaving)
15:44gdi2k has joined IRC (gdi2k!~gdi2k@57.190.1.21)
15:44vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:49
<alkisg>
vagrantc: AWEsome news; pam_exec is all we need, we don't have authentication problem anymore: http://irclogs.ltsp.org/
15:50
Since we'll already have the user geometry and the user is there, we can get the password via pam_exec, test it against ssh, and return success or failure from pam_exec, replacing pam_unix completely
15:51
passwd and group will be merged from chroot+server on boot so that accountsservice will pick them up, while gshadow and shadow won't need any hashes, not even like LDM_HASH_PASSWORD, as pam_exec can auth the screensaver too
15:52
I tried hooking pam_exec to auth, and it works beautifully; I'll even arrange so that ltsp-pamauth can work without ltsp too (in lan environments where they want ssh-based auth and optionally sshfs)
15:55
<quinox>
neat
15:55
<vagrantc>
alkisg: that is good news!
15:56
<alkisg>
No blockers for ltsp19 anymore, just a matter of scheduled work
15:56GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 258 seconds)
15:56
<vagrantc>
i know scotty looked into pam_exec originally ... wonder why
15:57
<alkisg>
It even shows stdout to gdm (I haven't tried lightdm yet, trying with buster-gnome), so I can notify "invalid password" or "unknown server"
15:57
I don't think I'll be able to do expiry though; those that want expiry can set up ldap-client in the chroot
15:59
<vagrantc>
that is exactly what scotty needed.
16:00
this is really exciting
16:00
pam_exec is included just about everywhere
16:03
alkisg: did i read the irc logs right in that it needs the username/id locally?
16:05alkisg_web has joined IRC (alkisg_web!822b520c@130.43.82.12.dsl.dyn.forthnet.gr)
16:06
<alkisg_web>
Meh work server got offline due to rain/power issues :/
16:06alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds)
16:07
<alkisg_web>
vagrantc, I did a quick try of adding the user right in the middle of pam_exec; it didn't work out
16:07
And, having the user geometry beforehand, allows to show them in gdm/lightdm, allows accountsservice to know them etc, much better
16:08
<vagrantc>
ok, so that's a bit of a regression, and a bit of a feature :)
16:08
<alkisg_web>
So I guess these 2 modes much be enough, i.e. passwd on the server + geometry on the client + pam_exec, or ldap in the client
16:08
Right, ldap on server only won't work anymore, the chroot will need to be configured properly
16:09
I do design a regex for user selection per client though, e.g. pc01 will only list a01-*/b01-*/c01-* users
16:09
<vagrantc>
so you need to rebuild the initrd every time you add a user?
16:09
<alkisg_web>
Configurable from lts.conf
16:09
<vagrantc>
or we have some other mechanism for transmitting user information?
16:10
<alkisg_web>
We could also have a small service; but for gsoc, I want to avoid web services if possible
16:10
<vagrantc>
this sounds like a good starting point
16:10
<alkisg_web>
I want web services to be another big design in the future, with epoptes-like control of the clients, and of course configuration sending
16:10
<vagrantc>
a little nervous about how the user data is transmitted ...
16:11
<alkisg_web>
In the future, https. Now, the initrd; but only passwd + group, not shadow
16:11
<vagrantc>
alkisg_web: we're talking /etc/passwd and /etc/group, basically?
16:11
<alkisg_web>
Right
16:12
I'll send them verbatim to the client, and the client can merge them on boot or whenever they see fit; I can also update them on ssh logins, or even via epoptes, but I'd like to avoid https for now
16:12
<vagrantc>
could set up a dedicated ssh user that just has access to two commands: cat /etc/passwd ; cat /etc/shadow
16:12
<alkisg_web>
But when are you going to run that command...
16:12
<vagrantc>
at boot
16:12gdi2k has left IRC (gdi2k!~gdi2k@57.190.1.21, Quit: Leaving)
16:12
<vagrantc>
rather than at initramfs generation
16:13
or rather, ltsp-cpio ...
16:13
or maybe even at *DM startup
16:13GodFather has joined IRC (GodFather!~rcc@2600:1007:b11f:4255:cc9d:c806:4f22:35cb)
16:13
<alkisg_web>
We'd need to tell users to restart the DM then
16:14
If we want them to refresh passwd
16:14
<vagrantc>
well, right now you need to tell users to reboot
16:14
<alkisg_web>
Or login
16:14
We can update passwd on login
16:14
<vagrantc>
or rather, with putting it in the initrd
16:14
<alkisg_web>
Eh we can automate that part on the server more easily
16:14
ltsp-initrd needs less than 1 sec
16:15
<vagrantc>
and a reboot of client
16:15
<alkisg_web>
If we want, we can put an inotify hook in /etc/passwd and update initrd 3 secs after last change
16:15
<vagrantc>
sure
16:15
<alkisg_web>
But, if someone is using epoptes, he can do it without all these
16:15
<vagrantc>
ah, true
16:16
<alkisg_web>
He can just run "ltsp-pamssh -temp-web-server" on the server, which would load a python simplehttpserver with just passwd and group,
16:16
and "ltsp-pamssh update-passwd" via epoptes on the client
16:16
And that command can restart the DM too
16:17statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
16:18
<alkisg_web>
could set up a dedicated ssh user that just has access to two commands: cat /etc/passwd ; cat /etc/shadow ==> would you ship such a package?
16:19
We can also only allow this via key authentication, and put the key to the initramfs
16:19
<vagrantc>
alkisg_web: i meant /etc/passwd and /etc/group
16:19
exactly
16:20
<alkisg_web>
OK imagine this without ltsp temporarily
16:20
<vagrantc>
or getent passwd ; getent group ...
16:21
<alkisg_web>
The sysadmin installs that service, copies the pamssh user key to the clients, and they can fetch the newer info whenever they want
16:21
Does it sound sane, security-wise?
16:21
If so, sure, we can focus there, as it won't require any other services as dependencies, just ssh on the server
16:23
Btw, with pam_exec and the user already existing, I can have the ssh socket owned by the user; e.g. "remoteapps without daemon" or whatever else we want
16:23
<vagrantc>
a little bit of a user discoverability risk ... some remote execution risk (though you can narrow that significantly with keys)
16:23
alkisg_web: the simplicity of having the pre-existing users is pretty compelling ... just curious about updating the passwd/group databases
16:23
<alkisg_web>
server: pamssh install => creates pamssh user without login shell, and they key; then the sysadmin copies that key to clients/root/.ssh/
16:24
About merging, I'm thinking of this: `merge min_uid=1001 max_uid=60000 regex='a.*|b.*|etc'`
16:24
<vagrantc>
the security of the ssh user effectively can gain root on any client ... which is basically also true of the tftp server
16:25
<alkisg_web>
That would keep administrator=uid 1000 a local user, in case it's needed for logging in completely locally
16:26
<vagrantc>
hard-coding specialized uid/gid information could have incompatibilities for individual installations
16:26
<alkisg_web>
Sure the tftp is a major security risk but not a lot we can do about that at this point
16:26
That's a user command
16:26
I.e. the sysadmin provided those values in the cmdline
16:26
(or in lts.conf etc)
16:26
<vagrantc>
yeah, just comparing the relative risks of tftp vs. the dedicated ssh user
16:27
alkisg_web: ok
16:27
<alkisg_web>
The other idea is to just read login.defs and merge all non system users; but I like the min_uid/max_uid/regex idea better, it's more versatile
16:27
<vagrantc>
if it's configurable, it's all good :)
16:27
<alkisg_web>
Or I could read the min/max from login.defs, and only allow a regex
16:28
regex can do "a* but not administrator"
16:28stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 258 seconds)
16:28
<alkisg_web>
I hope people won't need groups there :P
16:28
<vagrantc>
merging system users is a bit tricky, since there may be group drift depending on the order of package installation
16:28
and system groups
16:28
<alkisg_web>
(e.g. allow only users from group "students" to login there"
16:28
I won't merge system users at all
16:28
I'll keep the target system users
16:29
<vagrantc>
i think technically uid range for non-system users is 500-60k+
16:29
<alkisg_web>
Or I could read the min/max from login.defs, and only allow a regex ==> hmm yeah I think that's best, and possibly allow for group regexes too
16:30
<vagrantc>
how do you merge, say, a different gid for "audio" on the client vs. the server?
16:30
by gid, or by name?
16:30
<alkisg_web>
By name
16:30
I don't touch system groups
16:31
So if alkisg is a member of audio, IF audio exists on the target, then alkisg will also be a member of that there, whatever the gid
16:31
uid nowadays is 1000+, even fedora went for that (from 500 previously)
16:31
And it's standarized in login.defs now
16:32
Yes pam_exec exists everywhere btw, all major distro installations and live cds; we're only missing the squashfs module and sshfs in some cases
16:32
...I'll try to include them at ltsp-update-image time, if it's possible
16:33
<vagrantc>
yeah, i know uid's are typically 1000+
16:33
including sshfs would only be possible with compatible architectures, i'm guessing?
16:34
(although with qemu-user-static or similar, many architectures can be "compatible")
16:34
<alkisg_web>
chroot apt install sshfs, if it's doable over overlay in the ltsp-update-image phase
16:34
Although if people want to use live cds as test images, I guess they won't mind to use guest accounts too, with local /home
16:35
As with normal chroots/VMs, they can just install ssh
16:35
*sshfs
16:35
<vagrantc>
right
16:35
<alkisg_web>
(guest accounts, or nfs3 homes; live cds can support those; or, live cds can run apt install sshfs on boot)
16:35
<vagrantc>
yup
16:36
<alkisg_web>
the squashfs module isn't important as all live cds have it already; and it can be normally installed in chroots/vms; btw debian-live also booted fine
16:36
(debian-live.iso with the ltsp boot code)
16:37
<vagrantc>
nice ... that even brings in calamares, so you could use LTSP to install systems :)
16:37
at least in theory ...
16:39alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:39
<vagrantc>
alkisg_web: so, for a simple implementation, you just copy passwd/group data into the initramfs. more sophisticated implementations are a bonus.
16:39
<alkisg_web>
I think i'll start with ltsp-pamssh as a separate package for lans
16:40
I think people will prefer to use that, instead of copying around passwd like they do now in some cases
16:40
I hope in 2 weeks it'll be ready
16:40
<vagrantc>
this is a dedicated ssh user to copy the passwd/group data?
16:40
ltsp-pamssh?
16:40
<alkisg_web>
That's the "pam service", but also the "merge passwd script"
16:41
I'm thinking to put everything in one file, so that sysadmins will be able to use ssh for authentication, and optionally sshfs for homes, in LANs, with a single file, without ltsp
16:41
<vagrantc>
ah.
16:41
<alkisg_web>
As I hope it'll work in all distors/DMs
16:41
And it'll be so much easier to setup than ldap/nfs4/kerberos etc
16:42
<vagrantc>
then ltsp-pamssh is a bit misleading for a name
16:42
<alkisg_web>
Eh it'll still be generated from the ltsp code; i just want to give them an easy way to install it
16:42
But sure, name suggestions are always welcome
16:42
I.e. I'm thinking that src: ltsp will generate 2 packages, ltsp and ltsp-pamssh
16:43
So later on they can apt install ltsp-pamssh, without ltsp
16:45
<vagrantc>
ltsp-pamssh sets up the pam_exec hooks that handle ssh authentication and sshfs homes (optionally) ... and the passwd/group sync?
16:45
<alkisg_web>
Right
16:45
And if we ever implement that special user, it'll do that too, server-side
16:46
(or a simplehttpserver, or anything else to ease the transfer)
16:46
<vagrantc>
so outside of ltsp, where would the passwd/group sync happen?
16:46
<alkisg_web>
The easiest would be epoptes again
16:46
<vagrantc>
got it
16:46
<alkisg_web>
Otherwise, scp + run ltsp-pamssh merge
16:47
or, on login
16:47
...maybe "on login" is the easiest one so far
16:47
<vagrantc>
well, obviously on login has a bootstrapping problem
16:47
<alkisg_web>
The initial one will happen with the installation
16:47
ltsp-pamssh setup => ask for a user on the server to authenticate, copy passwd, etc
16:48
like joining an AD domain, I think that asks for an AD administrator or something
16:48
<vagrantc>
right
16:48
and syncing would also have to happen as an administrator
16:49
as arbitrary users could do evil things
16:49
<alkisg_web>
Eh it needs root on the client, so it's safe
16:49
Btw pam_exec runs the script as root (and user gid), so we have enough rights to update passwd
16:49
<vagrantc>
but sync on login?
16:49
right
16:50
just a question of how you get the updated data
16:50
<alkisg_web>
Users don't manually run it there; it's pam_exec; users don't really have control over it
16:50
If the user authenticates against the server, he can login, and he can get the group/passwd over ssh
16:50
There's no "rights abuse"
16:50
<vagrantc>
"get the group/passwd over ssh" is where the user on the server has control
16:51
<alkisg_web>
...all normal users can cat passwd
16:51
We don't do anything to protect from that
16:51
<vagrantc>
yes, but i wouldn't trust the output from arbitrary users
16:51
<alkisg_web>
I don't get it
16:51
pam_exec calls our script, which ssh's to the server using the user name/password, and our script gets the data
16:52
<vagrantc>
cat /etc/passwd ... vagrant:x:0:0: ...
16:52
<alkisg_web>
Do you mean that the user might be able to put things in PATH and make `cat` misbehave?
16:52
<vagrantc>
exactly
16:52
<alkisg_web>
If we run /bin/cat, we don't rely on PATH
16:53
<vagrantc>
but you rely on the existance of /bin/cat
16:53
<alkisg_web>
And how can the user block that?
16:53
<vagrantc>
you're running as the user's login shell ... all sorts of trickery can happen
16:53
<alkisg_web>
We're not running a shell at all
16:54
ssh can run a command, not a shell
16:54
<vagrantc>
oh *really* ? :P
16:54
i bet you if the user's shell is /bin/false you won't be able to run arbitrary commands.
16:54
<alkisg_web>
The user can't set his shell to /bin/false
16:55
<vagrantc>
i'm pretty sure a shell is still run
16:55
<alkisg_web>
Let's formalize this. If you have an example where the user can actually harm us, no matter how careful we are, then we shouldn't sync on login via the user
16:56
If this is just hypothesis, we can research if it's possible or not
16:56
(btw note that that's what ltsp does currently :P)
16:56
<vagrantc>
at this point it's a hypothesis informed by overwhelming best practices: you don't trust unsanitized input
16:57
<alkisg_web>
I don't expect the user to be able to alter the input
16:57
Without the sysadmin allowing it first
16:57
<vagrantc>
i don't assume the limitations of our imagination are the best security protocol
16:58
<alkisg_web>
If there's a known security issue with ssh, we can just report it
16:58
<vagrantc>
and therefore defer to knowledge about best practices
16:58
<alkisg_web>
But we can't rely on hypotheses that ssh might have a bug there
16:58
<vagrantc>
it's not a bug in ssh, it's a bug in the proposed method of passwd/group retrieval
16:59
(which maybe we already have)
16:59
<alkisg_web>
If I `ssh user@server /bin/cat /etc/passwd` and the user is able to alter the output of that command, I'd consider it a grave security flow of ssh
17:00
<vagrantc>
i don't see why; the computer is doing what you asked it to do
17:00
you're getting the output of the commands run on that server, however the user has configured their environment
17:01
*trusting* that output blindly to configure the local system is the security vulnerability
17:01
<alkisg_web>
I'm saying that the user environment should be able to affect /bin/cat /etc/passwd
17:01
If it is, it sounds like a security flaw
17:02
<vagrantc>
yes, the user environment should be able affect /bin/cat /etc/passwd
17:02
but it's not a security flaw...
17:02woernie has joined IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de)
17:02
<alkisg_web>
And have /bin/cat be suid root?
17:02
<vagrantc>
and while i *might* be able to prove that's true, i can't prove that it's not true
17:02
<alkisg_web>
Then all users can become root, by just running a command :)
17:03
<vagrantc>
the user could run fakechroot to make /bin/cat be whatever they want
17:03
for example
17:03
<alkisg_web>
The user can configure ssh to run fakeroot?
17:03
Then why can't he configure login too?
17:04
So that people logging in as admin, will login to his fakeroot?
17:04
<vagrantc>
you're looking at this from the wrong angle
17:04ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
17:04
<alkisg_web>
There are fences of security that need to be respected, for security to work
17:04
<vagrantc>
it's not that it would compromise login on the server ... that actually requires root privledges
17:04
<alkisg_web>
If we assume that a user can chroot to his nfs root and becore root there, all is lost
17:05
If we assume that the user can modify the sshd config... it's about the same
17:05
<vagrantc>
but to trust all the data from an arbitrary user to then configure, say, login on the client ... that's where the problem exists
17:05
<alkisg_web>
Btw, you do know ltsp currently does just that, right? :)
17:05
<vagrantc>
yes, i know
17:06
i do like to think the next version of ltsp will fix bugs in the old system? :)
17:06
<alkisg_web>
Eh, we can't fix everything :D
17:06
<vagrantc>
agreed
17:06
<alkisg_web>
So ok, let's pass on the "sync on login" idea
17:07
I'm not convinced it's a security flaw, but anyway
17:07
<vagrantc>
we can touch on it another time
17:07
<alkisg_web>
It could sync using the special user then
17:07
<vagrantc>
with a dedicated user, you can configure an ssh key to specifically do exactly one command
17:08
<alkisg_web>
Although of course anyone can get that ssh key and login to the server then
17:08
Which is a much greater security flaw
17:08
Even if it's just to run a specific command
17:08
<vagrantc>
yes, anyone can get that ssh key and run /bin/cat /etc/passwd
17:08
to their hearts content
17:09
<alkisg_web>
Yes, but if an ssh CVE is discovered, it's an issue there
17:09
<vagrantc>
indeed
17:09
<alkisg_web>
And there's python simplehttpserver
17:10
<vagrantc>
because hand-crafting an http server will always be secure? :)
17:10
<alkisg_web>
E.g. epoptes, or scp, or anything non-automated
17:10
I run the server, run the sync command via epoptes, close the server
17:10
They might hack pythonsimplehttpserver in 5 secs; it's a risk I'll have to take
17:11
<vagrantc>
at any rate ... shunting everything into the biggest security hole we have, tftp the initramfs ... seems like the least problematic at this point
17:11
<alkisg_web>
Dunno from all those, I think I like the "sync on login" best
17:12
If some actual exploit is ever found... we might have implemented the big web service already at that point
17:12
True; well, they could put the initramfs locally, and hope that's more secure
17:13
<vagrantc>
i'll try to test that sync on login is a bad idea, and if i can prove it, it's settled?
17:13
<alkisg_web>
Of course
17:13
If you're worried that much, no need to test, I can discard that anyway
17:13
<vagrantc>
if i can't prove it, i'm not convinced ... but if i can
17:14
<alkisg_web>
And tell users to use scp/epoptes/etc
17:14
<vagrantc>
the user login could trigger a sync or something reasonbly safely
17:14GodFather has left IRC (GodFather!~rcc@2600:1007:b11f:4255:cc9d:c806:4f22:35cb, Ping timeout: 250 seconds)
17:14
<alkisg_web>
Ah
17:14
<vagrantc>
you just can't trust the output from the user's account
17:14
<alkisg_web>
We can tell them "login as admin to sync"
17:14
If the admin wants to hack his own system, ...
17:15
<vagrantc>
possibly
17:15
<alkisg_web>
I.e. instead of a special user, "the user that set it up initially"
17:16
<vagrantc>
this is for manually administered machines, not ltsp clients?
17:16
<alkisg_web>
Yes, I'm trying to solve the general problem first
17:16
Then specialize it to ltsp
17:16
ltsp clients can use the initramfs for now
17:17
<vagrantc>
got it
17:17
the admin is defined how?
17:17
<alkisg_web>
The user that runs: sudo ltsp-pamssh setup
17:17
which in turn asks: give user/pass of server, to copy passwd
17:18
And saves the user name somewhere in /etc/ltsp/
17:18
sudo ltsp-pamssh setup alkisg@server ==> so the server trusted user is "alkisg"
17:18
And the connection server is defined/saved as "server"
17:19
<vagrantc>
why not sudo ltsp-pamssh setup user@server
17:19
rather than asking
17:19
<alkisg_web>
^ :)
17:19* alkisg_web wonders if webchat propagates things slowly...
17:19
<vagrantc>
alkisg_web: you're writing too fast
17:20
:)
17:20
<alkisg>
;)
17:20
Yey, server is up again
17:20
<vagrantc>
but at least we landed at the same place that time
17:21
i'm a little curious about "saving" the administrative user
17:21
<alkisg>
We can also check if the user is a sudoer (from the geometry), and sync if he is
17:21
Assuming that if he's a sudoer on the server... well, he can hack the server directly
17:21
<vagrantc>
right
17:22
<alkisg>
Hopefully, bob that WAS a sudoer in our saved geometry, won't be a malicious user in the new geometry :P
17:22
<vagrantc>
so, they already have sudo locally
17:22
so whatever authentication is already handled
17:22
<alkisg>
(previous sysadmin that got away, then a user with the same name came)
17:23
I'm not sure what you mean there
17:23
<vagrantc>
old names should be reserved ...
17:23
<alkisg>
Initially, they have normal accounts/pam, so sudo and all, locally
17:23
<vagrantc>
can't stop everyone from shooting themselves in the foot all the time
17:23
<alkisg>
After the setup, only a few local accounts will remain, if any
17:24
So shadow will only have their local passwords
17:24
All the other shadow entries will be cleared, as pam_exec/ssh will be used instead
17:24
<vagrantc>
hmmm...
17:25
so how do you define which local users are saved?
17:25
<alkisg>
With the regex
17:25
<vagrantc>
ok
17:25
<alkisg>
sudo ltsp-pamssh setup user@server --regex='a* b*'
17:26
A min_uid/max_uid may still be needed
17:26
<vagrantc>
--preserve-local-users="$
17:26
regexp"
17:27
or something other than --regex
17:27
:)
17:27
<alkisg>
And after all that, pam_exec will check if the user has a local shadow entry, then it'd chain to pam_unix
17:27
If it's a non-system user, without a shadow entry, it'd use ssh for authentication
17:28
<vagrantc>
wouldn't pam_exec just exit at that point and let the chain move on down the line?
17:28
<alkisg>
That; I don't know yet the correct terminology
17:28
<vagrantc>
i think that's generally how pam works ... you can have modules which fail and it's ok and it moves on to the next
17:29
it's configurable ... some might require success, some might be optional, etc.
17:29
<alkisg>
In my first test today, i completely replaced pam_unix with pam_exec
17:29
I guess I'll put it above
17:30
At that point, I hadn't thought about local users yet
17:30
<vagrantc>
anyways, sounds reasonably good thus far
17:30
<alkisg>
But it'll be nice to have, for non-ltsp clients
17:30
If non-ltsp pam* works, and we get users outside of ltsp,we'll have earlier DM testing too
17:30
That it works in all distros/DEs
17:31
Thanks for the input vagrant, as always :)
17:33
<vagrantc>
alkisg: thanks for all the good ideas and implementation! :)
17:38woernie has left IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de, Ping timeout: 248 seconds)
18:44GodFather has joined IRC (GodFather!~rcc@2600:1007:b11a:ac68:cc9d:c806:4f22:35cb)
19:22GodFather has left IRC (GodFather!~rcc@2600:1007:b11a:ac68:cc9d:c806:4f22:35cb, Ping timeout: 248 seconds)
19:22lucascastro has joined IRC (lucascastro!~lucascast@177.185.131.162)
19:47alkisg_web has left IRC (alkisg_web!822b520c@130.43.82.12.dsl.dyn.forthnet.gr, Remote host closed the connection)
20:06lucascastro has left IRC (lucascastro!~lucascast@177.185.131.162, Quit: Leaving)
20:28ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
20:43spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 244 seconds)
20:56Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:43ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:05adrianorg has left IRC (adrianorg!~adrianorg@177.18.50.202, Ping timeout: 272 seconds)
22:06kjackal has left IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60, Ping timeout: 258 seconds)
22:31ogra has left IRC (ogra!~ogra@ubuntu/member/ogra, Ping timeout: 258 seconds)
22:35adrianorg has joined IRC (adrianorg!~adrianorg@177.18.50.202)
23:51dsjii has joined IRC (dsjii!~david@2600:380:a035:2b15:68db:caff:fe86:8f41)