bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Limiting environment use for setuid/setgid programs only?


From: Sven Joachim
Subject: Re: Limiting environment use for setuid/setgid programs only?
Date: Wed, 19 Apr 2023 20:08:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On 2023-04-17 18:23 -0400, Thomas Dickey wrote:

> On Sat, Apr 15, 2023 at 10:29:38AM +0200, Sven Joachim wrote:
>> The ramifications of CVE-2023-29491 can be limited by configuring
>> ncurses with --disable-root-environ.  However, this disables all use of
>> the ncurses environment variables by the superuser which has the
>> potential to break scripts and makefiles.
>
> Revisiting this - what scripts are setting $TERMINFO (or $TERMINFO_DIRS)
> that root should pay attention to?

I don't know - would have to look e.g. on codesearch.debian.net, but
that takes quite some time due to a large number of hits for TERMINFO.

> (makefiles don't _need_ environment variables)

True, but at least two packages in Debian set TERMINFO at build time,
rather than using tic's -o option.

> These pathnames are addressed by the --disable-root-environ option:
>
>    TERMINFO
>    TERMINFO_DIRS
>
> as well as these (not used in Debian):
>
>    TERMCAP
>    TERMPATH
>
>> Would it be possible to add a new option that only limits environment
>> use for setuid/setgid programs, like the --disable-root-access behavior?
>
> It's possible,
>
> But I don't see why root should be more permissive than a setuid program :-)

Because there is no possibility of privilege escalation when root uses
these environment variables or their own terminfo files under
/root/.terminfo, unlike with setuid programs.  If the superuser loads
any such files from directories where other users have write access,
it's the superuser's own fault.  Right now with --disable-root-environ,
root _has_ to use the system terminfo database for any custom terminfo
entries and thus affect every user on the system, which might be
undesired.

There are many other cases of such behavior, e.g. the dynamic linker
ignoring LD_LIBRARY_PATH and other dangerous environment variables for
setuid programs, but not when root runs a program.

Cheers,
       Sven



reply via email to

[Prev in Thread] Current Thread [Next in Thread]