Recent

Author Topic: self elevation in linux  (Read 3296 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: self elevation in linux
« Reply #15 on: December 02, 2020, 11:19:55 pm »
Spot on. This is also why daemons which need to bind to low ports start as root but then switch to a non-privileged user after accomplishing that. Anything else introduces a serious security issue. Expecting any user to run a user application as root is just so wrong on so many levels, quite apart from the assumption that a normal user has root access.

Actually, in Debian at least there's been some "give and take" over the last few years.

There are two commands which users expect to be able to run but which demand elevated privilege: ping and traceroute. In the past I've noted that one or two releases allocated a capability to the binaries that allowed them to get the resources they needed without running as root, but then the distro reverted to running them setuid root: my own suspicion is that the amount of grief caused to standard backup etc. procedures outweighed the elegance. Note that at no time did these programs demand a password from the user.

I've used POSIX capabilities fairly heavily on a couple of occasions, but particularly over the last few months when I've been porting a program that used low-numbered UDP ports, created a unix-domain socket in /var/run and various other things. It's possible to integrate the initial capability manipulation into the IDE's compilation commands, /but/ since the capabilities are stored in filesystem extended attributes they're lost if you tar a file or move it around: I suspect that this was a conscious decision on the part of the kernel developers.

There's not an option to set capabilities with the standard install command, neither is it able to invoke an external command to handle that sort of thing. The way I worked around the problem was to have the program announce what commands were needed to get things set up properly if it realised it had a problem, at that point I had to use sudo to sort things out but that was only needed when I loaded an updated version.

Obviously in at least some cases there's other possibilities which exploit egid etc.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 14197
  • Probably until I exterminate Putin.
Re: self elevation in linux
« Reply #16 on: December 03, 2020, 01:41:14 am »
Actually, in Debian at least there's been some "give and take" over the last few years.
Be careful, total nonsense. Debian has become MORE strict, not less.
You are playing a Trump? IOW really inexcusable nonsense. >:D >:D >:D

Apart from the user, you need to add to the group that has sufficient rights first and then add to the device group.
« Last Edit: December 03, 2020, 01:44:47 am by Thaddy »
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: self elevation in linux
« Reply #17 on: December 03, 2020, 09:23:54 am »
Actually, in Debian at least there's been some "give and take" over the last few years.
Be careful, total nonsense. Debian has become MORE strict, not less.
You are playing a Trump? IOW really inexcusable nonsense. >:D >:D >:D

Apart from the user, you need to add to the group that has sufficient rights first and then add to the device group.

I didn't say- and certainly didn't intend to imply- that Debian had relaxed its security. What I was trying to point out is that Debian started off with those two programs running setuid root, then for either one or two versions set the appropriate capability on the binary instead of using setuid, and then reverted to setuid when capabilities were obviously giving problems. If you don't understand that then RTFM >:-|

I can't remember the timescale: not recent, possibly Jessie and/or Wheezy. I was definitely seeing the capability vanish if files were moved around for any reason (e.g. move the /usr tree onto a different physical device).

So please don't accuse me of total nonsense. And definitely keep Trump out of it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: self elevation in linux
« Reply #18 on: December 05, 2020, 11:49:28 pm »
You mean
Code: Pascal  [Select][+][-]
  1. ping -f
I think ?

That is a good example of what I said several posts ago. On bullseye, using ping -f does require root but if an ordinary user tries it, it does not prompt for root password.  It tells you, only superuser is allowed to do that. The application, ping, is never told the root password.

My point was that if it did prompt for a password, that would be like training the user to supply the password on demand, a very bad thing. And the thing the OP was planning to do.

Lets keep on topic here, random applications asking for the root password is a bad thing !

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: self elevation in linux
« Reply #19 on: December 06, 2020, 10:37:01 am »

$ sudo getcap `which ping`
/usr/bin/ping = cap_net_raw+ep


That's from Buster, and shows that Debian has started allocating the net_raw capability to the binary again. I'm not fiddling with it right now since I've got other things to do, but if that binary were moved around I'd expect the capability to be lost until the superuser reinstated it.

If you go back to the previous release you see


$ ls -l `which ping`
-rwsr-xr-x 1 root root 61240 Nov 10  2016 /bin/ping


i.e. it's run setuid root.

If a program wants to "self elevate" it would be reasonable for it to prompt for the user's password before it enables the capability. That's a slightly different can of worms since it will probably mean interacting with PAM in some way.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018