13 Nov
2024
13 Nov
'24
12:29 p.m.
Something that I have noticed on my bitfolk box but not other Debian machines.
I am running Debian 12.7
When I go "sudo -s" it shows a new login on a different pts.
I logged in via ssh at 16.14 and then went: sudo -s
If I run "w" I now appear to be logged in twice (1.52 is the current time):
addw pts/0 2001:4d48:ad51:2 16:14 40.00s 0.02s 0.01s sudo -s
addw pts/1 2001:4d48:ad51:2 01:52 3.00s 0.00s 0.01s sudo -s
So I am now on a different tty and the old one shows idle time.
I get similar results if I run "who".
ps shows interesting results:
# ps -f
UID PID PPID C STIME TTY TIME CMD
root 28669 28644 0 01:52 pts/1 00:00:00 sudo -s
root 28670 28669 0 01:52 pts/1 00:00:00 /bin/bash
root 28979 28670 0 01:59 pts/1 00:00:00 ps -f
# ps -fp28644
UID PID PPID C STIME TTY TIME CMD
root 28644 1819 0 01:51 pts/0 00:00:00 sudo -s
What is happening ?
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information:
https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>
13 Nov
13 Nov
3:03 p.m.
On 13/11/2024 12:29, Alain D D Williams via BitFolk Users wrote:
Something that I have noticed on my bitfolk box but
not other Debian machines.
I am running Debian 12.7
When I go "sudo -s" it shows a new login on a different pts.
I logged in via ssh at 16.14 and then went: sudo -s
If I run "w" I now appear to be logged in twice (1.52 is the current time):
addw pts/0 2001:4d48:ad51:2 16:14 40.00s 0.02s 0.01s sudo -s
addw pts/1 2001:4d48:ad51:2 01:52 3.00s 0.00s 0.01s sudo -s
So I am now on a different tty and the old one shows idle time.
I get similar results if I run "who".
ps shows interesting results:
# ps -f
UID PID PPID C STIME TTY TIME CMD
root 28669 28644 0 01:52 pts/1 00:00:00 sudo -s
root 28670 28669 0 01:52 pts/1 00:00:00 /bin/bash
root 28979 28670 0 01:59 pts/1 00:00:00 ps -f
# ps -fp28644
UID PID PPID C STIME TTY TIME CMD
root 28644 1819 0 01:51 pts/0 00:00:00 sudo -s
What is happening ?
according to man sudo, it's expected behaviour if an i/o logging plugin
is configured.
comparing /etc/sudo.conf on the bitfolk box and your other debian
machines may highlight the cause.
regards, Tim
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
3:32 p.m.
On Wed, Nov 13, 2024 at 03:03:22PM +0000, Tim Dickson via BitFolk Users wrote:
according to man sudo, it's expected behaviour if
an i/o logging plugin is
configured.
comparing /etc/sudo.conf on the bitfolk box and your other debian machines
may highlight the cause.
regards, Tim
All these are the same:
/etc/sudo.conf
/etc/sudoers
/etc/sudo_logsrvd.conf
/etc/pam.d/sudo
/etc/pam.d/sudo-i
Ah, the difference is that on my bf machine my login is in the group 'sudo',
that allows me to be 'sudo -s'. Add myself to that group on another machine and
I see the same behaviour.
I found this explanation:
https://unix.stackexchange.com/questions/785637/sudo-results-in-a-new-sessi…
OK: I accept it but it does result in something that I do not expect when I run
"who".
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information:
https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>
3:50 p.m.
Hi Alain,
On Wed, Nov 13, 2024 at 03:32:54PM +0000, Alain D D Williams via BitFolk Users wrote:
I found this explanation:
https://unix.stackexchange.com/questions/785637/sudo-results-in-a-new-sessi…
OK: I accept it but it does result in something that I do not expect when I run
"who".
I can't say it has ever bothered me but you can turn off "use_pty" to
get back the previous behaviour can't you?
As far as I'm aware this is just the behaviour of sudo with use_pty set,
which is the Debian default yes?
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
4 p.m.
On Wed, Nov 13, 2024 at 03:50:34PM +0000, Andy Smith via BitFolk Users wrote:
I can't say it has ever bothered me but you can
turn off "use_pty" to
get back the previous behaviour can't you?
Yes I can, and behaviour reverts.
As far as I'm aware this is just the behaviour of
sudo with use_pty set,
which is the Debian default yes?
Yes. But I had not seen the behviour before as I usually do not create users in
the group sudo -- but this happened with the BF machine.
This is why I was surprised when I saw it.
Not a problem, just not what I expected.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information:
https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>
4:11 p.m.
Hi,
On Wed, Nov 13, 2024 at 04:00:05PM +0000, Alain D D Williams via BitFolk Users wrote:
On Wed, Nov 13, 2024 at 03:50:34PM +0000, Andy Smith
via BitFolk Users wrote:
Oh, what I mean is that I wasn't aware that this behaviour would or
could change just because of any group setting. As far as I am aware
this is entirely because of the /etc/sudoers line:
Defaults use_pty
and would apply whether you used a user that is in group sudo or
not (although again, the Debian default is that only root and users in
group sudo can use sudo at all).
Are you sure that the sudo group has any bearing on this?
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
As far as I'm aware this is just the
behaviour of sudo with use_pty set,
which is the Debian default yes?
Yes. But I had not seen the behviour before as I usually do not create users in
the group sudo -- but this happened with the BF machine.
4:17 p.m.
On Wed, Nov 13, 2024 at 04:11:28PM +0000, Andy Smith via BitFolk Users wrote:
Are you sure that the sudo group has any bearing on
this?
Only in a roundabout way: if I am not in group sudo then I cannot go "sudo -s"
and thus will just go "su" which does not do this.
So the problem is more the way that my head works - sorry.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information:
https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>
9:45 p.m.
On 2024-11-13 12:29+0000, Alain D D Williams via BitFolk Users wrote:
# ps -f
UID PID PPID C STIME TTY TIME CMD
root 28669 28644 0 01:52 pts/1 00:00:00 sudo -s
root 28670 28669 0 01:52 pts/1 00:00:00 /bin/bash
root 28979 28670 0 01:59 pts/1 00:00:00 ps -f
# ps -fp28644
UID PID PPID C STIME TTY TIME CMD
root 28644 1819 0 01:51 pts/0 00:00:00 sudo -s
What is happening ?
Kernel < 6.1 that allows the process you sudo'd to write back to the
user who ran the sudo when not using a pty for the process. It is fixed
in later kernels, but is a linux specific thing AKA antijack.
I took the decision to not fix this in please (my sudo-like program) as
it's fixed in kernel now, and if you were to:
cat image.iso | please dd of=/dev/sdd
Then that dd would be run in a pty and the data has to be bucketed
through the master/slave of the pty, which isn't green. When not using a
pty it's just stdio as normal.
I don't think many people use the pty logger either, I could be entirely
wrong about it all, but went with my gut and didn't think it was ideal
given all the code overhead, which itself can present more issues
(signal handling too etc). Everything is solvable of course...
Ed
10:24 p.m.
On Wed, Nov 13, 2024 at 09:45:47PM +0000, Ed Neville via BitFolk Users wrote:
Kernel < 6.1 that allows the process you sudo'd
to write back to the
user who ran the sudo when not using a pty for the process. It is fixed
in later kernels, but is a linux specific thing AKA antijack.
I am running 6.1.0-27, that number will not get smaller, so I have removed it.
Makes my poor brain happy -- thanks.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information:
https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>
11:17 p.m.
Hi Ed,
On Wed, Nov 13, 2024 at 09:45:47PM +0000, Ed Neville via BitFolk Users wrote:
Kernel < 6.1 that allows the process you sudo'd
to write back to the
user who ran the sudo when not using a pty for the process. It is fixed
in later kernels, but is a linux specific thing AKA antijack.
I think the above paragraph may have unintentionally given the
impression that Debian 12 (bookworm) ships with a kernel (currently
6.1.0-27) that protects against this. However, as far as I understand
things:
- CONFIG_LEGACY_TIOCSTI option is available from kernel 6.2.something
(i.e. not in Debian 12 (bookworm))
- Even then it defaults to 'y' which means that things can still do
TIOCSTI unless you take action to disable it.
- Even then there is TIOCLINUX which can do the same bad things as
TIOCSTI.
So in summary, I believe that every program in Debian 12 (bookworm) that
doesn't use a new pty is vulnerable to having its terminal hijacked by
anything it executes, and the "use_pty" setting in sudo is still
necessary if one doesn't want to risk that. There are alternative
mitigations.
If this is not correct please let me know!
(I am aware that what you have written is compatible with my assertions
above, it's just that I think it is open to other interpretations.)
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
14 Nov
14 Nov
12:16 a.m.
On Wed, Nov 13, 2024 at 11:17:36PM +0000, Andy Smith via BitFolk Users wrote:
- CONFIG_LEGACY_TIOCSTI option is available from
kernel 6.2.something
(i.e. not in Debian 12 (bookworm))
- Even then it defaults to 'y' which means that things can still do
TIOCSTI unless you take action to disable it.
I think this will involve setting sysctl dev.tty.legacy_tiocsti to 0
once running a new enough kernel. Unsure if the default sysctls for
Debian 13 will do that.
- Even then there is TIOCLINUX which can do the same
bad things as
TIOCSTI.
Looks like TIOCLINUX was disabled for non-root users from kernel 6.7
onwards. Debian testing is on 6.11.5-1 at the moment and 6.10.11-1 is
available in stable-backports.
So, I think those are your choices for kernel protection.
An alternative mitigation choice could be a seccomp wrapper like
antijack:
https://github.com/hartwork/antijack
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
5:42 p.m.
On 2024-11-14 00:16+0000, Andy Smith via BitFolk Users wrote:
Looks like TIOCLINUX was disabled for non-root users
from kernel 6.7
onwards. Debian testing is on 6.11.5-1 at the moment and 6.10.11-1 is
available in stable-backports.
So, I think those are your choices for kernel protection.
Seems I am outdated. I could have sworn I saw it didn't work in 6.1 - I
could be hallucinating, but when I tested it on Sid a while back, it
didn't work then, looks like LEGACY_TIOCSTI is on by default now. *sigh*
that's bothered me as a while back when I tested in Sid it defaulted to
off.
The cases that bother me more are things like the web servers that start
with a root binding, then CGI execute as lower users. Asking all user
applications to put guards in place doesn't seem sane for reasons
mentioned earlier. Starting a task as a low priv user with full
password-less elevation rights, is another issue, if the subprocess can
then put 'sudo nasty' into the TTY, that's a problem too.
Putting a password restriction around what you're not happy with,
protects against a lot of paste mishaps too!
Thanks for researching the current state of it, I thought this was
closed as fixed in kernel defaults now, absolute bonkers.
Ed
37
days inactive
38
days old
11 comments
4 participants
participants (4)
-
Alain D D Williams -
Andy Smith -
Ed Neville -
Tim Dickson