Re: Bug#1036933: screen-udeb: Should screen really be installed setgid utmp?
On 2023-06-26 12:19 +0200, Axel Beckert wrote:
> Sven Joachim wrote:
>> Recently I noticed that the screen program in the screen-udeb
>> package is installed setgid utmp, and I wonder if this actually
>> makes any sense.
>
> I suspect that setgid utmp indeed is not needed the installer context
> from a general viewpoint, but screen is rather picky about its
> permissions, especially setgid and setuid. (See below.) So our
> decision back then was based on the following:
>
> Screen has two supported ways to edit /var/log/wtmp:
>
> A) via setgid utmp
> B) via libutempter
>
> Because we didn't want to pull in another library (libutempter) into
> the installer when we created screen-udeb (and hence adding the need
> to provide a libutempter udeb as well as libutempter freezes before
> installer releases, etc.), we decided continue to use (A) for the
> screen-udeb while the remainder of the screen package switched from
> (A) to (B).
>
>> While I do not have much experience with the installer, I would expect
>> it to run all programs as root anyway, so there should be no need for
>> setgid there.
>
> Good point. Then again, it shouldn't do any harm for the very same
> reason, right?
Well, the security context causes some restrictions as I mentioned in
the original mail. Probably those do not really matter, but you never
know what crazy things people want to do.
> Screen is particular picky about its and /run/screen's permissions and
> it might refuse to work if they're not set to one of the supported
> permission combinations. See /usr/share/doc/screen/README.Debian.gz
Thanks, I was not aware of that.
> So changing them definitely needs some additional tests. In general,
> I'd prefer to avoid that, especially in the udeb where it does no
> harm.
It seems that if /run/screen does not exist, screen creates its with
appropriate permissions if it can. So unless some other component in
the installer has created the directory already, this should work.
>> Having screen installed setgid sets up a secure execution environment
>> that precludes the use of certain environment variables, see the
>> "Secure-execution mode" section in ld.so(8). Recently ncurses has also
>> started to restrict such programs, see #1034372.
>
> Thanks for that pointer, wasn't aware of that kind of feature. But I
> fail to see how
> https://invisible-island.net/ncurses/NEWS.html#index-t20230408 is
> related.
It isn't. What is relevant is that ncurses 6.4-3 started using the
"--disable-root-environ" configure option to mitigate the security
impact of CVE-2023-29491. I did not close #1034372 back then because we
did not backport any fixes.
> https://invisible-island.net/ncurses/NEWS.html#index-t20230418 and
> https://invisible-island.net/ncurses/NEWS.html#index-t20230423 look
> more related, though. Maybe a typo in #1034372, 08 vs 18?
In the 20230418 patchlevel ncurses started to use getauxval(AT_SECURE)
(well, on GNU/Linux at least) which is a bit more thorough than the
previous check, but for setuid/setgid programs the behavior is the same
as before.
> Anyway, IMHO ncurses should not care about setuid/setgid when already
> called under root. It makes sense under any other user, though.
You have to discuss that with the glibc developers if you want to
change it. This is the way setgid programs are currently treated.
>> Hopefully none of this matters much. I have CC'ed debian-boot, as the
>> people working on the installer will be much more qualified to give
>> advice than I am.
>
> Cyril Brulebois wrote:
>> Given the first sentence of this last paragraph, it looks like we're not
>> considering doing anything for Bookworm at this time
>
> That's also the reason why I didn't reply back in May: We were way to
> deep into the Bookworm freeze to do anything on that front IMHO. And
> the installer just worked fine with regards to its screen usage.
Nice to hear, hopefully it stays that way.
Cheers,
Sven
Reply to: