Re: MATE 1.8 has now fully arrived in Debian
On 27/06/14 10:53, Svante Signell wrote:
> Before this part of the thread dies out, can anybody comment on this,
> Simon, Ansgar, Jean-Christophe, ...?
>
> On Thu, 2014-06-26 at 16:32 +0200, Svante Signell wrote:
>> Maybe I'm naive but doesn't utmp(5) solve this problem?
>>
>> who(1) tells me in clear-text if I'm logged in locally or remote:
>> Are there serious security problems with ancient utmp that cannot be
>> solved?
I don't know, and when its man page describes system programs depending
on its integrity as "foolish", that is ambiguous enough to put me off.
If you want to do the research to demonstrate that the file format is
unambiguous, every process with access to group utmp updates that file
in a secure way, and those processes cannot be tricked into updating
that file in a way that would mislead another process into believing
false things about a user login, go ahead; I'd be happy to be proved
wrong. (utmp and wtmp are group-writable, so every process in group utmp
needs to be trusted; compare with logind, which I think can only be told
about new sessions by root, typically in libpam-systemd shortly before a
setuid() to the target uid.)
As it is, every time I've seen code that interacts with utmp in things
like gdm or PAM modules, it has been accompanied by comments about
determining the meaning of the file by guesswork and vague conventions
(e.g. the file format doesn't seem to have been designed to represent
X11, leading to things like overloading ut_host and ut_line with "if it
has a colon in it, it's probably an X11 display"). That doesn't exactly
fill me with confidence.
My confidence that every implementation of logind (i.e. currently only
one) has been designed with security in mind is considerably greater
than my confidence that every implementation of updating utmp has been
designed with security in mind.
> Even systemd use utmp: man -k utmp shows:
> systemd-update-utmp (8) - Write audit and utmp updates at runlevel
> changes and shutdown
> systemd-update-utmp-runlevel.service (8) - Write audit and utmp updates
> at runlevel changes and shutdown
> systemd-update-utmp-shutdown.service (8) - Write audit and utmp updates
> at runlevel changes and shutdown
You might notice that there is no mention here of *reading* utmp:
systemd appears to be treating it as write-only, so that software that
relies on utmp can read values out of it that are at least as accurate
as they were before systemd.
S
Reply to: