Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #248066 > unrolled thread

Help with suid (bash)

Back to article view | Back to linux.debian.user

Contents

  Help with suid (bash) rhkramer@gmail.com - 2022-05-10 14:00 +0200
    Re: Help with suid (bash) <tomas@tuxteam.de> - 2022-05-10 14:20 +0200
    Re: Help with suid (bash) Charles Curley <charlescurley@charlescurley.com> - 2022-05-10 16:30 +0200
      Unlocking (remote/local), was Re: Help with suid (bash) David Wright <deblis@lionunicorn.co.uk> - 2022-05-10 18:10 +0200
        Re: Unlocking (remote/local), was Re: Help with suid (bash) Greg Wooledge <greg@wooledge.org> - 2022-05-10 21:10 +0200
          Re: Unlocking (remote/local), was Re: Help with suid (bash) David Wright <deblis@lionunicorn.co.uk> - 2022-05-10 21:30 +0200
        Re: Unlocking (remote/local), was Re: Help with suid (bash) Charles Curley <charlescurley@charlescurley.com> - 2022-05-11 01:20 +0200
          Re: Unlocking (remote/local), was Re: Help with suid (bash) Greg Wooledge <greg@wooledge.org> - 2022-05-11 03:10 +0200
          Re: Unlocking (remote/local), was Re: Help with suid (bash) David Wright <deblis@lionunicorn.co.uk> - 2022-05-11 05:10 +0200
            Re: Unlocking (remote/local), was Re: Help with suid (bash) <tomas@tuxteam.de> - 2022-05-11 07:10 +0200
              Re: Unlocking (remote/local), was Re: Help with suid (bash) David Wright <deblis@lionunicorn.co.uk> - 2022-05-11 18:10 +0200
                Re: Unlocking (remote/local), was Re: Help with suid (bash) <tomas@tuxteam.de> - 2022-05-11 20:30 +0200
                  Re: Unlocking (remote/local), was Re: Help with suid (bash) David Wright <deblis@lionunicorn.co.uk> - 2022-05-12 01:00 +0200
          Re: Unlocking (remote/local), was Re: Help with suid (bash) Dan Ritter <dsr@randomstring.org> - 2022-05-11 14:10 +0200
      Re: Help with suid (bash) rhkramer@gmail.com - 2022-05-10 18:50 +0200

#248066 — Help with suid (bash)

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 (<myuserid>) rather than as 
root. 

Aside: This was (and still is) under Debian Wheezy -- I know I should upgrade.  
I do have installations of Jessie and Buster on other computers and am getting 
ready to install Bullseye on another machine which might replace the Wheezy 
machine (if I can run TDE under Bullseye).  Getting these scripts working as 
intended (that is, using suid) is part of my effort to do that.

Problem: I tried to use suid to allow the scripts to be run by me, but with 
the permissions of root  but I could not get that to work.  

Aside: I do run those scripts with the aid of a (compiled) c helper program 
that switches to root and then runs the appropriate script (setuid( 0 ) and 
then system( "<bash_script_filename>" ). 

The script to mount a partition looks like this (comments deleted, and some 
things shown "generically" for privacy / security):

#!/bin/bash 
/sbin/cryptsetup luksOpen /dev/sd<ann> <luks_device_name> && /bin/mount 
/dev/mapper/<luks_device_name> <mount_point>

The ownership and permissions that I tried to use (I tried some variations, 
and I have different permissions at the moment) were:

-rwsr-xr-x 1 root <groupid_that_includes_my_userid> 1412 Aug 31  2014 
<bash_script_filename>

(I should remove the read and execute permission from all, but that is what I 
had at that time.)

Why can't I run that successfully as myself (<my_userid>), and what could I do 
to make it run?

When I invoke the script with those permissions, including suid, I get a 
response like:

$ <bash_script_filename>
WARNING!!! Possibly insecure memory. Are you root?
Cannot open device /dev/sd<ann> for read-only access.
$

To clarify: when I run these scripts with the aid of the c helper program, the 
scripts work as intended and I get no error messages.

Thanks for any input!

[toc] | [next] | [standalone]

#248067

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 10, 2022 at 07:50:18AM -0400, rhkramer@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 (<myuserid>) 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

[toc] | [prev] | [next] | [standalone]

#248072

On Tue, 10 May 2022 07:50:18 -0400
rhkramer@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
> (<myuserid>) 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/

[toc] | [prev] | [next] | [standalone]

#248074 — 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 rhkramer@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
> > (<myuserid>) 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.

[toc] | [prev] | [next] | [standalone]

#248077 — 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 rhkramer@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.)

[toc] | [prev] | [next] | [standalone]

#248080 — 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<ann> <luks_device_name> && /bin/mount \
/dev/mapper/<luks_device_name> <mount_point>

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-AAAAAAAA { # unlock /home before logging in or transfers
      ping -c 1 -W 1 AAAAAAAA | grep 'bytes from' # wake it up first
      date && ssh -X AAAAAAAA -l unlock
  }

(The ping seems to help those powerline devices that some hosts use.)

¹ "a general aversion to being in root"

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248081 — Re: Unlocking (remote/local), was Re: Help with suid (bash)

On Tue, 10 May 2022 11:08:23 -0500
David Wright <deblis@lionunicorn.co.uk> 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/

[toc] | [prev] | [next] | [standalone]

#248083 — 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 <deblis@lionunicorn.co.uk> 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.

[toc] | [prev] | [next] | [standalone]

#248085 — 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 <deblis@lionunicorn.co.uk> 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), rhkramer@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 (<myuserid>) 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 unlo<TAB>ac<TAB> than ssh acer -l unlock,
and I'm lazy and would rather type wake-ac<TAB> than walk 30 yards
and a flight of stairs, plus return, just to press a button.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#248086 — Re: Unlocking (remote/local), was Re: Help with suid (bash)

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#248094 — Re: Unlocking (remote/local), was Re: Help with suid (bash)

On Wed 11 May 2022 at 07:05:47 (+0200), tomas@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.

[toc] | [prev] | [next] | [standalone]

#248104 — Re: Unlocking (remote/local), was Re: Help with suid (bash)

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#248112 — Re: Unlocking (remote/local), was Re: Help with suid (bash)

On Wed 11 May 2022 at 20:26:20 (+0200), tomas@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.

[toc] | [prev] | [next] | [standalone]

#248089 — Re: Unlocking (remote/local), was Re: Help with suid (bash)

Charles Curley wrote: 
> On Tue, 10 May 2022 11:08:23 -0500
> David Wright <deblis@lionunicorn.co.uk> 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-

[toc] | [prev] | [next] | [standalone]

#248076

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).

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web