A recent use-case on Slackware made me re-visit CVE-2005-4890
in the context of "su -c". Particularly, shadow's implementation
as of shadow 4.1.5.

During the discussions of this CVE (see footer links), it was
pointed out shadow's fix is partial given interactive su remains
vulnerable to tty-hijacking. It was also mentioned this vector
is less worrisome given use cases for interactive su are primarily
privilege escalation.

The CVE was always a bit controversial with many believing
using su and sudo to drop privileges is unsafe and more an
administration issue than a design flaw.

All that said, at the very least would it be reasonable to
apply the same threat-assessment criterion to the crippling
of "su -c" and not drop the controlling tty for the case when
the callee is root?

Slackware doesn't use PAM so the fix in shadow relies on a
TIOCNOTTY ioctl() request and not a setsid() call. One result
of this change is summarized in the table below:

                                        shadow 
                             4.1.4.3   4.1.5.1   4.1.5.1+patch*

1. As unpriv user user1:
xterm -e su -c $COMM          SUCCESS    FAIL     SUCCESS
xterm -e su user2 -c $COMM    SUCCESS    FAIL     FAIL

2. As root:
xterm -e su user1 -c $COMM    SUCCESS    FAIL     FAIL

-----
* See attached

Cheers.

--mancha