Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Wed 11 May 2022 at 20:26:20 (+0200), to...@tuxteam.de wrote: > On Wed, May 11, 2022 at 11:07:09AM -0500, David Wright wrote: > > [...] > > > But after two posts about background information on setuid shell > > scripts, you now write "the worst antipattern is to misuse tech > > to force people to follow some nonsensical rituals". Strong words. > > Sorry if I was unclear. The point I was trying to make is that > OpenSSH allows you to change the behaviour we are discussing > if you wish so. So it /doesn't/ follow that antipattern. I don't know what the antipattern is, that openssh doesn't follow. > As to the other points? Well: > > 0. if you want to be able to login directly as root, /and/ >with a password, change the server's /etc/sshd_config Perhaps I need to make it clear that: . I have set a password for root. . I can login as root at the console, using that password. . I do not want to login as root by password from any other system, be it mine or anyone else's. . I do not want to force, persuade, or hint that anyone else should follow my preferences. > 1. if you can be bothered to set up a key for root, use >that (generally preferrable to 0.) I have. On all my systems, root can login as root, by key, on any other of my systems. And the same for me as me. Other users (which includes me) aren't set up to login by key or password to the root account: they use su. (Or avoid login with sudo.) The recipe I posted for the OP doesn't mention or use keys, or use the root account. The secondary script (unlock-…) that I use to run the main one does use ssh, but is silent on the authentication method. Charles suggested that the OP just run things as root. As I was posting a script that's really designed for remote unlocking, I thought it helpful to point out that in an unaltered Debian system, you wouldn't be able to login as root. (I see no reason against basing answers on a vanilla Debian stable system.) > 1a. you can even limit what a private key owner is able to >do: e.g. "only backup". So even if someone manages to >steal your remote backup's private key, (s)he'll only >able to trigger a backup I didn't read the OP's question as necessitating that sort of configuration. Anyone who thinks to the contrary is free to add their own reply. > 2. if you don't like 0..1a, there's still sudo. You can >fine-tune what commands (and what parameters go with >those) each (local or remote) user is allowed to invoke, >and even whether they're supposed to issue a password >for that or they get it "password-less". Isn't that what I did: I spelled out the exact limitations that I impose, with the actual lines from the sudoers file, complete with their parameters and partial values, including the fact that after quoting (or not) the password to log in, they're not expected to quote it again just for sudo. > What's not to like? I don't know. I posted a script that does more than what the OP wanted to achieve (which was to avoid using the root account), and because it's a real script, I tried to add any information that explained specifics that might not be immediately understood, like: . why it's in .profile, . what /home/0 is, . why it prints a line between unlocking and mounting, . who unlock is, . why unlocking a system remotely might be attractive, . why lines were added to the sudoers file. > What's missing? Evidently, a discussion on becoming root. And if you're following along closely, and ignore the likely circumstances of my script being run, you might point out that there's no obvious way for user unlock to unmount or lock /home. Cheers, David.
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Wed, May 11, 2022 at 11:07:09AM -0500, David Wright wrote: [...] > But after two posts about background information on setuid shell > scripts, you now write "the worst antipattern is to misuse tech > to force people to follow some nonsensical rituals". Strong words. Sorry if I was unclear. The point I was trying to make is that OpenSSH allows you to change the behaviour we are discussing if you wish so. So it /doesn't/ follow that antipattern. As to the other points? Well: 0. if you want to be able to login directly as root, /and/ with a password, change the server's /etc/sshd_config 1. if you can be bothered to set up a key for root, use that (generally preferrable to 0.) 1a. you can even limit what a private key owner is able to do: e.g. "only backup". So even if someone manages to steal your remote backup's private key, (s)he'll only able to trigger a backup 2. if you don't like 0..1a, there's still sudo. You can fine-tune what commands (and what parameters go with those) each (local or remote) user is allowed to invoke, and even whether they're supposed to issue a password for that or they get it "password-less". What's not to like? What's missing? Cheers -- t signature.asc Description: PGP signature
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Wed 11 May 2022 at 07:05:47 (+0200), to...@tuxteam.de wrote: > On Tue, May 10, 2022 at 10:08:20PM -0500, David Wright wrote: > > On Tue 10 May 2022 at 17:12:25 (-0600), Charles Curley wrote: > > [...] > > > IOW, though logging in to root by password is ok at the console, > > it's not ok when remote. ➀ > > I assume you know all that you can set "PermitRootLogin yes" in > your /etc/ssh/sshd_config (the default is "prohibit-password", > which fits the behaviour you are describing). > > It's not recommended, (for good reasons!), but hey, it's your box, > and you decide what you deem to be "secure enough". After all, > security is context-dependent, and the worst antipattern is to > misuse tech to force people to follow some nonsensical rituals > (it happens far too often, alas, but OpenSSH isn't that sort of > software). > > So you can change that, if you wish so. What's your point? Well, Charles seemed to have difficulty with understanding my first paragraph, which I wrote merely to explain that I assume a root password has been set. It seems odd to get three follow-ups, all of which centre on the consequences of the ssh configuration chosen by the Debian developers for a bullseye installation. When you write a script to unlock and mount a partition, you can do it in two lines: # udisksctl unlock --block-device /dev/foo # mount /dev/bar /baz but that's useless as it stands, and needs to be embedded into your ecosystem to be useful, which is why I posted my script, a real example. But after two posts about background information on setuid shell scripts, you now write "the worst antipattern is to misuse tech to force people to follow some nonsensical rituals". Strong words. Perhaps you could elaborate on which specific rituals you find offensive. I can't work out whether you're criticising my script, or the Debian developers for the way they're now choosing to configure ssh, or the linux kernel developers for the ban on setuid shell scripts. Cheers, David.
Re: Unlocking (remote/local), was Re: Help with suid (bash)
Charles Curley wrote: > On Tue, 10 May 2022 11:08:23 -0500 > David Wright wrote: > > > That complicates unlocking partitions remotely because, even if you > > can log in as root, you normally can't log in remotely as root. > > ??? I log in as root over SSH all the time. Most sshd configs either prevent root from logging in directly or prevent root from logging in with a password (ssh key required). -dsr-
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Tue, May 10, 2022 at 10:08:20PM -0500, David Wright wrote: > On Tue 10 May 2022 at 17:12:25 (-0600), Charles Curley wrote: [...] > IOW, though logging in to root by password is ok at the console, > it's not ok when remote. ➀ I assume you know all that you can set "PermitRootLogin yes" in your /etc/ssh/sshd_config (the default is "prohibit-password", which fits the behaviour you are describing). It's not recommended, (for good reasons!), but hey, it's your box, and you decide what you deem to be "secure enough". After all, security is context-dependent, and the worst antipattern is to misuse tech to force people to follow some nonsensical rituals (it happens far too often, alas, but OpenSSH isn't that sort of software). So you can change that, if you wish so. What's your point? Cheers [1] cf. man 5 sshd_config -- t signature.asc Description: PGP signature
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Tue 10 May 2022 at 17:12:25 (-0600), Charles Curley wrote: > On Tue, 10 May 2022 11:08:23 -0500 > David Wright wrote: > > > That complicates unlocking partitions remotely because, even if you > > can log in as root, you normally can't log in remotely as root. > > ??? I log in as root over SSH all the time. This sequence will be familiar to a lot of people: $ ssh acer -l root ➀ root@acer's password: Permission denied, please try again. root@acer's password: ^C 130 $ /bin/su - ➁ Password: bullseye on /dev/sda5 toto05 # ssh acer Linux acer 5. … …➂ … … Last login: Tue May 10 … acer # mv -i .ssh/authorized_keys .ssh/hide-authorized_keys ➃ acer # logout Connection to acer closed. # ssh acer ➄ root@acer's password: Permission denied, please try again. root@acer's password: ^C 130 # IOW, though logging in to root by password is ok at the console, it's not ok when remote. ➀ However, when I'm already root ➁, logging in by key is ok because acer's root has my public key and I can prove I have the private key. ➂ If acer's root doesn't have my public key ➃, then I still can't login to acer with ssh because password is all that's left. ➄ I don't give root's public key to other users, where "other" includes me. I presume that in some respect, your systems differ. > > I use a special user called unlock, whose home directory is on > > /var/local/, to unlock my /home partitions: > > Unlock? What does "unlock" mean in this context? It looks like a > synonym for "mount". If so, it's an unnecessary opportunity for > confusion. And it sounds like it's more complicated than it need be. /etc/fstab could mount /home, except for the context: > > > On Tue 10 May 2022 at 07:50:18 (-0400), rhkra...@gmail.com wrote: > > > > Background: 8 years ago I wrote a set of scripts to help me mount and > > > > unmount > > > > LUKS encrypted partitions as needed and as myself () rather > > > > than as > > > > root. So any complexity, outside the script itself, arises from: unlock has a home directory that's not on /home (which is still locked), unlock can run just one program, and with strictly limited arguments, unlock doesn't have to authenticate to use that sudo command, I'm lazy and would rather type unloac than ssh acer -l unlock, and I'm lazy and would rather type wake-ac than walk 30 yards and a flight of stairs, plus return, just to press a button. Cheers, David.
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Tue, May 10, 2022 at 05:12:25PM -0600, Charles Curley wrote: > David Wright wrote: > > I use a special user called unlock, whose home directory is on > > /var/local/, to unlock my /home partitions: > > Unlock? What does "unlock" mean in this context? It looks like a > synonym for "mount". If so, it's an unnecessary opportunity for > confusion. And it sounds like it's more complicated than it need be. I think it implies some kind of encryption, requiring a key to mount.
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Tue, 10 May 2022 11:08:23 -0500 David Wright wrote: > That complicates unlocking partitions remotely because, even if you > can log in as root, you normally can't log in remotely as root. ??? I log in as root over SSH all the time. > > I use a special user called unlock, whose home directory is on > /var/local/, to unlock my /home partitions: Unlock? What does "unlock" mean in this context? It looks like a synonym for "mount". If so, it's an unnecessary opportunity for confusion. And it sounds like it's more complicated than it need be. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Tue 10 May 2022 at 13:02:41 (-0400), Greg Wooledge wrote:
> On Tue, May 10, 2022 at 11:08:23AM -0500, David Wright wrote:
[> > On Tue 10 May 2022 at 08:21:00 (-0600), Charles Curley wrote:]
> > > Why the aversion to doing things as root? Why not just run your scripts
> > > as root? This is exactly the sort of thing that is reserved to root for
> > > reasons of security.
> >
> > That complicates unlocking partitions remotely because, even if you
> > can log in as root, you normally can't log in remotely as root.
>
> But you *can* typically sudo on the remote system, which is what is
> actually being suggested here. I think.
It's certainly what's being suggested by /me/, as can be seen in my:
sudo udisksctl unlock --block-device "$j"
but that's not how rhkramer (judging by the 12:40:25 response¹) and
I would take Charles' post as meaning, but rather:
$ su -
# cryptsetup luksOpen /dev/sd && /bin/mount \
/dev/mapper/
presumably with the command wrapped, as now, in a script.
> (Also, you'd be surprised how many systems *do* allow remote root logins,
> either from a quasi-trusted set of source IPs, or using key auth only,
> or both.)
I do myself, using keys, but only local-root to remote-root. Having an
ordinary user use sudo means that one script suffices to unlock /home
both from a remote machine or at the console. Of course, it's a separate
ordinary user because of their non-/home home directory.
Simplification and generalisation are quite important to me, so as you
can see, the script will work unchanged on any of my hosts, and though
I mentioned unlock-acer, that function is one of several that are
created on the fly, in this case from:
function unlock- { # unlock /home before logging in or transfers
ping -c 1 -W 1 | grep 'bytes from' # wake it up first
date && ssh -X -l unlock
}
(The ping seems to help those powerline devices that some hosts use.)
¹ "a general aversion to being in root"
Cheers,
David.
Re: Unlocking (remote/local), was Re: Help with suid (bash)
On Tue, May 10, 2022 at 11:08:23AM -0500, David Wright wrote: > > On Tue, 10 May 2022 07:50:18 -0400 rhkra...@gmail.com wrote: > > Why the aversion to doing things as root? Why not just run your scripts > > as root? This is exactly the sort of thing that is reserved to root for > > reasons of security. > > That complicates unlocking partitions remotely because, even if you > can log in as root, you normally can't log in remotely as root. But you *can* typically sudo on the remote system, which is what is actually being suggested here. I think. (Also, you'd be surprised how many systems *do* allow remote root logins, either from a quasi-trusted set of source IPs, or using key auth only, or both.)
Re: Help with suid (bash)
On Tuesday, May 10, 2022 10:21:00 AM Charles Curley wrote: > Why the aversion to doing things as root? Why not just run your scripts > as root? This is exactly the sort of thing that is reserved to root for > reasons of security. I may think about that some more, but it is a general aversion to being in root, or switching to root while I'm doing "ordinary" things (like accessing information on some mounted-on-demand LUKS partitions).
Unlocking (remote/local), was Re: Help with suid (bash)
On Tue 10 May 2022 at 08:21:00 (-0600), Charles Curley wrote:
> On Tue, 10 May 2022 07:50:18 -0400 rhkra...@gmail.com wrote:
>
> > Background: 8 years ago I wrote a set of scripts to help me mount and
> > unmount LUKS encrypted partitions as needed and as myself
> > () rather than as root.
>
> Why the aversion to doing things as root? Why not just run your scripts
> as root? This is exactly the sort of thing that is reserved to root for
> reasons of security.
That complicates unlocking partitions remotely because, even if you
can log in as root, you normally can't log in remotely as root.
I use a special user called unlock, whose home directory is on
/var/local/, to unlock my /home partitions:
$ cat /var/local/home/unlock/.profile
[[ $- = *i* ]] && printf '%s\n' "(This is $HOME/.profile 2022 March 02 on
$HOSTNAME, $(sed -e 's/.* \([^ ]\+\) *$/\1/;q' /etc/apt/sources.list) on
$(findmnt -n -o SOURCE,LABEL -M /))"
[ ! -f /home/0 ] && printf '\n%s\n\n' "/home is mounted already" && sleep 1 &&
exit 9
for j in /dev/disk/by-partlabel/*-Home; do
printf 'Unlocking %s\n' "$j"
sudo udisksctl unlock --block-device "$j"
done
printf 'Checking partition\n' # in case there's a pause
mount /home
sleep 1
if [ ! -f /home/0 ]; then
printf '%s\n' "/home is now mounted" && exit 0
else
printf '\n%s\n\n' "/home is NOT mounted" && sleep 1 && exit 99
fi
#
$
So after introducing itself (note: my sources.list is doctored),
it checks that /home is not already mounted (note: there's an
empty file called 0 in the /home directory on the rootfs), and
then unlocks any partition whose PARTLABEL ends with -Home.
It then mounts the one that matches the entry in fstab.
Here's how I call it remotely:
$ type unlock-acer
unlock-acer is a function
unlock-acer ()
{
ping -c 1 -W 1 acer | grep 'bytes from';
date && ssh -X acer -l unlock
}
$
And, of course, that would normally follow a call to wake-acer
(assuming it's not a laptop):
$ type wake-acer
wake-acer is a function
wake-acer ()
{
wakeonlan 22:44:66:88:aa:cc
}
$
If you're not in group sudo (I have a root password), you'd
require lines like these in /etc/sudoers.d/foo:
User_Alias LOCKER = unlock
Host_Alias MYHOSTS = …, acer, …
Cmnd_Alias UNLOCKING = /usr/bin/udisksctl unlock --block-device
/dev/disk/*/*
Cmnd_Alias LOCKING = /usr/bin/udisksctl lock --block-device /dev/disk/*/*
Defaults:LOCKER !authenticate
LOCKER MYHOSTS = UNLOCKING, LOCKING
Note that all this is running on a home LAN. I would do things
differently in a more open environment.
As for setuid scripts, they haven't been allowed since I started using
Debian in Sept 1996, which was on Debian's first release, buzz, running
2.0 kernels. Allegedly there was a Perl method of doing it that I never
tried out. It was meant to create a Chinese wall between anything that
originated from outside and the rest of the program.
Cheers,
David.
Re: Help with suid (bash)
On Tue, 10 May 2022 07:50:18 -0400 rhkra...@gmail.com wrote: > Background: 8 years ago I wrote a set of scripts to help me mount and > unmount LUKS encrypted partitions as needed and as myself > () rather than as root. Why the aversion to doing things as root? Why not just run your scripts as root? This is exactly the sort of thing that is reserved to root for reasons of security. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Followup: Re: Resolved: Re: Help with suid (bash)
By the way, thanks to all who replied! One followup below. On Tuesday, May 10, 2022 08:20:10 AM rhkra...@gmail.com wrote: > Ok, thanks very much! > > That resolves that -- I do have another way of doing it (the c helper > program), I just don't like it -- I'll probably continue to use that but > think about alternatives. Ahh, the (an) obvious (finally ;-) alternate solution is to incorporate the luks and mount commands directly in the c helper program, as that at least avoids the confusion (to me) of having both a script and a c program for each partititon (and I could consider "parameterizing" the partitions). E.g., in my (typical) c program, instead of setuid( 0 ); system( "" ); do setuid( 0 ); system( "/sbin/cryptsetup luksOpen /dev/sd " ); system( "/bin/mount /dev/mapper/ " );
Re: Help with suid (bash)
On Tue, May 10, 2022 at 07:58:39AM -0400, Greg Wooledge wrote: > On Tue, May 10, 2022 at 07:50:18AM -0400, rhkra...@gmail.com wrote: > > Aside: even though this is not a Debian specific question, I often use > > debian- > > user as my first resource in asking Linux questions. > > It's Linux-specific, though. I poked around a bit. NetBSD seems to honour it... but grudgingly. Here's from their sh(1) man page [1] BUGS Setuid shell scripts should be avoided at all costs, as they are a significant security risk. "At all costs": that's a tall order :-) Dunno what the other BSDs say. As to the other Unices... which Unices? ;-) Cheers [1] https://man.netbsd.org/sh.1 -- t signature.asc Description: PGP signature
Resolved: Re: Help with suid (bash)
(Intentionally top posting) Ok, thanks very much! That resolves that -- I do have another way of doing it (the c helper program), I just don't like it -- I'll probably continue to use that but think about alternatives. On Tuesday, May 10, 2022 07:58:39 AM Greg Wooledge wrote: > The Linux kernel does not honor the setuid bit on a script. Any script. > Anything that's executed via a shebang, rather than an ELF header. > > This is for security purposes, as there's some sort of race condition > or something. I forget the exact details, but the point is, you can't > do this. Find another solution.
Re: Help with suid (bash)
On Tue, May 10, 2022 at 07:50:18AM -0400, rhkra...@gmail.com wrote: > Aside: even though this is not a Debian specific question, I often use debian- > user as my first resource in asking Linux questions. > > Background: 8 years ago I wrote a set of scripts to help me mount and unmount > LUKS encrypted partitions as needed and as myself () rather than as > root. TL;DR use sudo. You must have had an outdated kernel version back then, I think. The setuid bit has been ignored for scripts in Linux since like... forever. If my memory doesn't fail me, it must have been around kernel 2.x, perhaps 3.x, so around of before 2010. I remember writing a setuid wrapper for a specific application back with kernel 2.0.36, so it must already have been a topic back then. There are many places out there as to why -- my search engine gave me this [1] one. You can, of course, patch your kernel. You could write a setuid wrapper (a small setuid C program written to call your script: a good exercise in writing security sensitive stuff -- did I get everything right? ;-) Or you can use a setuid wrapper written for you (called sudo). Even this one doesn't get everything right from the get-go. I'd still recommend this latter options. The one I wrote Back Then [TM] surely has more holes than sudo. Cheers [1] https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts -- t signature.asc Description: PGP signature
Re: Help with suid (bash)
On Tue, May 10, 2022 at 07:50:18AM -0400, rhkra...@gmail.com wrote: > Aside: even though this is not a Debian specific question, I often use debian- > user as my first resource in asking Linux questions. It's Linux-specific, though. > -rwsr-xr-x 1 root 1412 Aug 31 2014 > The Linux kernel does not honor the setuid bit on a script. Any script. Anything that's executed via a shebang, rather than an ELF header. This is for security purposes, as there's some sort of race condition or something. I forget the exact details, but the point is, you can't do this. Find another solution.
