Source: shadow
Followup-For: Bug #628843
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
su/runuser are provided by util-linux these days. Can this bug be
closed?
- -- System Information:
Debian Release: 12.0
APT prefers testing
APT policy: (530, 'testing'), (520, 'unstable'), (500, 'testing
On Mon, Oct 03, 2016 at 11:07:59PM +0200, up201407...@alunos.dcc.fc.up.pt wrote:
> It's an invasion of privacy, as I said, for normal users.
Sure, but that's not my use case.
> In your case, if you're changing to an unprivileged user without a shell nor
> password, probably some sort of "locked"
Quoting "Simon Ruderich" :
It's an invasion of privacy, as I said, for normal users.
In your case, if you're changing to an unprivileged user without a
shell nor password, probably some sort of "locked" account, how is an
attacker going to make use of TIOCSTI to exploit your system?
(Assum
On Mon, Oct 03, 2016 at 09:58:23PM +0200, up201407...@alunos.dcc.fc.up.pt wrote:
> Anyways, it is bad admin practice and/or an invasion of privacy to su to an
> unprivileged user.
Please explain to me why this is bad admin practice.
Lets assume I have an unprivileged user which is used to execute
On Mon, Oct 03, 2016 at 09:49:08PM +0200, Karel Zak wrote:
> Yes, I'm thinking about this way (as discussed on util-linux
> mailing list), but it's relatively complex.
I have a working solution here. It's a standalone program and not
very well tested, but works fine for me. Just tell me if you wan
Quoting "Karel Zak" :
Anyways, it is bad admin practice and/or an invasion of privacy to su
to an unprivileged user.
This has been talked alot in the past, in most of the times even
closed as "WONTFIX".
What I'm saying is, it's OK if you can't come up with something.
Better use 'su -c'
On Mon, Oct 03, 2016 at 09:34:14PM +0200, Simon Ruderich wrote:
> On Mon, Oct 03, 2016 at 09:22:50PM +0200, up201407...@alunos.dcc.fc.up.pt
> wrote:
> > Loss of job control in the shell.
>
> I'm confused. I'm not talking about removing the controlling
> terminal, but instead spawning a new sessio
On Mon, Oct 03, 2016 at 09:22:50PM +0200, up201407...@alunos.dcc.fc.up.pt wrote:
> Loss of job control in the shell.
I'm confused. I'm not talking about removing the controlling
terminal, but instead spawning a new session, opening a new pts
and connecting that to the program. This way the program
Quoting "Simon Ruderich" :
Loss of job control in the shell.
On Mon, Oct 03, 2016 at 04:22:47PM +0200, Karel Zak wrote:
The problem is that we don't want to use setsid() in all situations,
because it will introduce regressions. From util-linux ReleaseNotes:
Hello,
Thanks for your quick repl
On Mon, Oct 03, 2016 at 04:22:47PM +0200, Karel Zak wrote:
> The problem is that we don't want to use setsid() in all situations,
> because it will introduce regressions. From util-linux ReleaseNotes:
Hello,
Thanks for your quick reply.
In which situations will this cause regressions? I tried to
On Mon, Oct 03, 2016 at 04:11:41PM +0200, up201407...@alunos.dcc.fc.up.pt wrote:
> Btw, at least in redhat based systems, su uses setsid() when the -c option
> is given, just like use_pty in sudo. Not sure if this is true in debian.
Yes, that's true in Debian as well.
Regards
Simon
--
+ privacy
On Mon, Oct 03, 2016 at 03:34:49PM +0200, Simon Ruderich wrote:
> @Karel: Could you please have a look at the patches in this bug
> report which use setsid() to create a new session and adapt your
> commit with a patch based on this approach? Sudo's use_pty option
> does the same to fix this issue
On Mon, Oct 03, 2016 at 04:11:41PM +0200, up201407...@alunos.dcc.fc.up.pt wrote:
> Quoting "Simon Ruderich" :
>
> Btw, at least in redhat based systems, su uses setsid() when the -c option
> is given, just like use_pty in sudo. Not sure if this is true in debian.
The problem is that we don't want
Quoting "Simon Ruderich" :
Btw, at least in redhat based systems, su uses setsid() when the -c
option is given, just like use_pty in sudo. Not sure if this is true
in debian.
On Sun, Oct 02, 2016 at 10:54:06AM +0200,
up201407...@alunos.dcc.fc.up.pt wrote:
Hello Simon,
This has been rece
On Sun, Oct 02, 2016 at 10:54:06AM +0200, up201407...@alunos.dcc.fc.up.pt wrote:
> Hello Simon,
>
> This has been recently patched by using seccomp to blacklist this ioctl.
>
> https://github.com/karelzak/util-linux/commit/8e4925016875c6a4f2ab4f833ba66f0fc57396a2
Hello,
This is an awful hack! Bla
Hello Simon,
This has been recently patched by using seccomp to blacklist this ioctl.
https://github.com/karelzak/util-linux/commit/8e4925016875c6a4f2ab4f833ba66f0fc57396a2
This message was sent using IMP, the Internet Messaging P
Package: login
Version: 1:4.2-3+deb8u1
Followup-For: Bug #628843
Hello,
Any news on this?
I'm deeply worried that this security issue in su was not fixed
since it was reported over 5 years ago! It still affects jessie
and sid. And the possible implications are not mentioned in the
man page.
As
found 1:4.1.5.1-1
This problem still exists in Wheezy.
--
Ismaël RUAU
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hello,
I think Ismaël has a point here:
> I'm bumping this bug to point out that the problem is not 100% fixed.
> Even though "su -c" is now safe, interactive "su" or "su -" are still at
> risk and this should probably be reflected here on the BTS.
I successfully used this on my up-to-date Squ
Hello,
I'm bumping this bug to point out that the problem is not 100% fixed.
Even though "su -c" is now safe, interactive "su" or "su -" are still at
risk and this should probably be reflected here on the BTS.
Unfortunately I don't see any way to fix this without removing the
controlling terminal
Hello,
One more point to be reviewed.
shadow-utils supports also configurations where PAM is not used.
In that case, su does not fork to exec the interactive shell / command, so
I cannot use setsid().
In that case, I intend to use:
#include
#include
#include
#include
#include
int f
Quoting Thijs Kinkhorst (th...@debian.org):
> Hi Christian,
>
> I'm just mailing to confirm that we did record the issue in our tracker and
> to
> point out that this issue is currently also discueed on oss-security:
> http://thread.gmane.org/gmane.comp.security.oss.general/5172
Thanks, Thijs,
Op donderdag 02 juni 2011 07:34:59 schreef Christian PERRIER:
> Security team, I need advice and help here. My co-maintainer for
> shadow, Nicolas, is more or less MIA, so I'm left nearly alone to
> maintain shadow. As Nicolas was also upstream, you understand how
> desperate is my situation..:-)
>
Hello,
Here is a patch proposal. It forwards the right signal to the child also
supports SIGTSTP.
I would appreciate if this could be reviewed by somebody more confident
with signal processing than me.
I expect sudo to have the same issue.
Also sg probably has the same issue (i.e. it cannot be
On Thu, Jun 02, 2011 at 07:34:59AM +0200, Christian PERRIER wrote:
> My expertise is, as you may expect, way outreached. So, in short, what
> I need is someone with enough expertise to look at this bug report and
> help deciding if adopting Redhat's patch is correct (assuming it
> applies: I'm not
-devel] Bug#628843: login: tty hijacking possible in "su"
via TIOCSTI ioctl
Reply-To: Daniel Ruoso , 628...@bugs.debian.org
X-CRM114-Status: Good ( pR: 39.0933 )
Package: login
Version: 1:4.1.4.2+svn3283-2+squeeze1
Severity: critical
After investigating why RedHat have a different behavior rega
Package: login
Version: 1:4.1.4.2+svn3283-2+squeeze1
Severity: critical
After investigating why RedHat have a different behavior regarding "su -c" I
found out that there was a patch in RedHat to prevent tty hijacking when using
"su -c".
What makes the hijacking possible is that "su -c" still give
27 matches
Mail list logo