Package: base-files
Version: 4.0.4
Severity: normal
Tags: security
Hello,
Context #1 : there is some work being done to to give the system
administrator the means to implement site-logging policies ; today’s
focus is to allow a Debian system administrator to disable, « the
Debian way », login records book-keeping, rather than relying on ugly
hacks. This bug report is a small step on the way to make this
possible (another step being the related Debian bug #488365... more to
come).
Context #2 : the files /var/log/{btmp,wtmp,lastlog} and /var/run/utmp
gather privacy-sensitive data (e.g. the IP address a user last logged
in from with ssh).
Disabling such logging is tricky enough on a current Debian system,
without the base-files postinst behaviour making it even harder...
which it actually does.
As an example, according to wtmp’s and lastb’s manpages, the standard
way to disable /var/log/{btmp,wtpm} logging is to simply delete these
files : no program should ever create them if them does not exist yet.
Nice. But... base-files’ postinst unconditionally creates these files
on install/upgrade if they don’t exist yet, thus enforcing login
book-keeping. Not nice at all, since this can provide a sysadmin with
a false sense of privacy/security, thinking he/she has disabled
a privacy-breaking feature whereas it will be silently re-enabled
later without he/she knowing it. That’s why I dared to tag this bug
« security ».
Temporary conclusion : it is currently impossible, in Debian, to use
the standard way to disable permanently e.g. /var/log/{btmp,wtmp}
logging, as next base-files’ upgrade will forcibly re-enable it.
My proposal is the following : provide a slick and clean way to
disable the automatic creation of /var/log/{btmp,wtmp,lastlog} and
/var/run/utmp in base-files’ postinst. IMHO, a global switch for these
four files would be enough, since a sysadmin willing to disable logins
logging is probably willing to do it globally.
I’m volunteering to provide a patch implementing the solution we’ll
choose. I’m not sure how to achieve this best. A few ideas and random
notes to start with :
(1) The best for CDDs would be to use debconf to ask/store this
setting, but debconf only has Priority: required, whereas
base-files is in Essential, so I don’t know if this is doable, or
even legal in regard to the Debian Policy.
(2) A simplistic file-existence-based switch, on the model of how the
/etc/nologin file is used ; a good and not too confusing name
would be hard to find, but this would be the easiest solution not
only to implement, but also to enable/disable e.g. in a CDD.
(3) A configuration variable in /etc/default/base-files would require
a CDD wanting to disable login records to edit another package’s
configuration file, which is forbidden by the Debian policy, so
this solution does not seem to be suitable.
Please note I’m intentionally setting severity normal to this bug,
which could be disputable : on the one hand, one could consider it as
a simple feature request, thus only deserving a wishlist severity ; on
the other hand, it really breaks the standard (and documented) way to
disable some login records book-keeping features.
More context : data retention has become a hot legal topic for ISPs
and other Online Service Providers (OSPs). There are many instances
where it is preferable to keep less information on users than is
collected by default on many systems. In the United States, there is
currently no requirement to retain data on users of a server, but you
may be required to provide all data on a user which you have retained.
OSPs can protect themselves from legal hassles and added work by
choosing what data they wish to retain.
Bye, thanks to have read entirely :)
--
intrigeri <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
