Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Dmitry Bogatov]

[2019-02-07 17:08] Thorsten Glaser 
>
> part   text/plain 869
> On Thu, 7 Feb 2019, Dmitry Bogatov wrote:
>
> > Hence, I refine my proposal -- create /var/log/dmesg as 640 in
> > initscripts, *only* if it does not already exists. Ignore
> > kernel.dmesg_restrict.
>
> +1

Here is patch, that solves issue at hand. Ideally, same logic should be
applied to fsck logs.

From 46c237df7999dc550289709f4955e787ddabaa55 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Mon, 11 Feb 2019 03:32:09 +
Subject: [PATCH] Ensure predictable permission on /var/log/dmesg (Closes:
 #867747)

  * debian/initscripts.postinst: do not create `/var/log/dmesg' during
package installation.

  * debian/src/initscripts/etc/init.d/bootlogs: create `/var/log/dmesg'
with predicatable permissions, if not already present.

With this change, if /var/log/dmesg was removed for whatever reason,
it will be recreated with predictable permissions and ownership, instead of
recreated as root:root and permissions, depending on umask of
`/etc/init.d/bootlogs' script.
---
 debian/initscripts.postinst|  2 +-
 debian/src/initscripts/etc/init.d/bootlogs | 17 +
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 2293045d..c6ac94d4 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -132,7 +132,7 @@ fi
 # Create initial log files
 #
 [ "$PREV_VER" ] || chmod 755 /var/log/fsck || :
-for F in /var/log/dmesg /var/log/fsck/checkroot /var/log/fsck/checkfs
+for F in /var/log/fsck/checkroot /var/log/fsck/checkfs
 do
if [ ! -f "$F" ] && touch "$F" >/dev/null 2>&1
then
diff --git a/debian/src/initscripts/etc/init.d/bootlogs 
b/debian/src/initscripts/etc/init.d/bootlogs
index 3ad7d8b5..686a2afb 100644
--- a/debian/src/initscripts/etc/init.d/bootlogs
+++ b/debian/src/initscripts/etc/init.d/bootlogs
@@ -16,19 +16,28 @@ PATH=/sbin:/usr/sbin:/bin:/usr/bin
 . /lib/init/vars.sh
 
 do_start () {
+   # If /var/log/dmesg exists, rotate it, otherwise touch it with
+   # reasonable default permsissions and ownership.
+   #
+   # savelog(8) preserves ownership and permissions, that were set by
+   # local system administrator.
+   if test -f /var/log/dmesg ; then
+   savelog -q -p -c 5 /var/log/dmesg
+   else
+   touch /var/log/dmesg
+   chown root:adm /var/log/dmesg
+   chmod 640 /var/log/dmesg
+   fi
+
# Save kernel messages in /var/log/dmesg
if which dmesg >/dev/null 2>&1
then
-   [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
dmesg -s 524288 > /var/log/dmesg
-   chgrp adm /var/log/dmesg || :
elif [ -c /dev/klog ]
then
-   [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
dd if=/dev/klog of=/var/log/dmesg &
sleep 1
kill $!
-   [ -f /var/log/dmesg ] && { chgrp adm /var/log/dmesg || : ; }
fi
 }
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Pierre Ynard]

> Hence, I refine my proposal -- create /var/log/dmesg as 640
> in initscripts, *only* if it does not already exists. Ignore
> kernel.dmesg_restrict.

Makes sense to me.

--
Pierre Ynard

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Thorsten Glaser]

On Thu, 7 Feb 2019, Dmitry Bogatov wrote:

> Hence, I refine my proposal -- create /var/log/dmesg as 640 in
> initscripts, *only* if it does not already exists. Ignore
> kernel.dmesg_restrict.

+1

//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Dmitry Bogatov]

[2019-02-05 17:28] Thorsten Glaser 
> > As I understand situation, I favor second option. So question is would
> > anybody be unhappy, if initscripts will override manual `chown/chmod' on
> > logs, created by initscripts.
>
> Yes.
>
> It’s fine to adjust permissions on first install, and 0640 root:adm
> are sensible defaults, but to change whatever the local admin then
> decides is not acceptable. (I think there’s a policy somewhere for
> this, even.)

This is how things are done now. At debian/initscripts.posting:135,
if /var/log/dmesg does not exists, it is touched with 640, root:adm,
permissions are preserved by `savelog -p'.

But if /var/log/dmesg gets removed, on next boot it will be recreated
with another default -- 644. I believe, this is how submitter got
world-readable /var/log/dmesg.

Hence, I refine my proposal -- create /var/log/dmesg as 640 in
initscripts, *only* if it does not already exists. Ignore
kernel.dmesg_restrict.

More objections?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Thorsten Glaser]

On Tue, 5 Feb 2019, Dmitry Bogatov wrote:

> As I understand situation, I favor second option. So question is would
> anybody be unhappy, if initscripts will override manual `chown/chmod' on
> logs, created by initscripts.

Yes.

It’s fine to adjust permissions on first install, and 0640 root:adm
are sensible defaults, but to change whatever the local admin then
decides is not acceptable. (I think there’s a policy somewhere for
this, even.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Dmitry Bogatov]

[2019-02-04 11:09] Javier M DAW 
> Would the attached patch do the trick? (/etc/init.d/bootlogs)

Thank you very much for your patch, but it seems that issue at hand
might need addition considerations, as pointed by Pierre in next email.

> --- a2019-02-04 11:01:02.0 +0100
> +++ b2019-02-04 11:03:45.0 +0100
> @@ -15,20 +15,62 @@
>  [ "$DELAYLOGIN" ] || DELAYLOGIN=yes
>  . /lib/init/vars.sh
>
> +# Source options
> +if [ -f /etc/default/bootlogs ]
> +then
> +. /etc/default/bootlogs
> +fi
> +[ "$LOGFILE_GROUP" ] || LOGFILE_GROUP="adm"
> +[ "$LOGFILE_MODE" ] || LOGFILE_MODE="640"
> +[ "$OBEY_DMESG_RESTRICT" ] || OBEY_DMESG_RESTRICT=no
> +[ "$LOGFILE_RESTRICT_MODE" ] || LOGFILE_RESTRICT_MODE="640"
> +
> +check_dmesg_restrict()
> +{
> +if [ `uname -s` = Linux ]
> +then
> +if which sysctl > /dev/null 2>&1
> +then
> +DMESG_RESTRICT=`sysctl -n kernel.dmesg_restrict`
> +else
> +DMESG_RESTRICT=`cat /proc/sys/kernel/dmesg_restrict`
> +fi
> +fi
> +
> +}
> +
> +update_logfile_perms () {
> +if  [ "$OBEY_DMESG_RESTRICT" = yes ]
> +then
> +check_dmesg_restrict
> +if [ "$DMESG_RESTRICT" = 1 ]
> +then
> +TARGET_MODE="$LOGFILE_RESTRICT_MODE"
> +else
> +TARGET_MODE="$LOGFILE_MODE"
> +fi
> +else
> +TARGET_MODE="$LOGFILE_MODE"
> +fi
> +
> +chmod "$TARGET_MODE" /var/log/dmesg || :
> +chgrp "$LOGFILE_GROUP" /var/log/dmesg || :
> +}
> +
>  do_start () {
>  # Save kernel messages in /var/log/dmesg
>  if which dmesg >/dev/null 2>&1
>  then
>  [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
>  dmesg -s 524288 > /var/log/dmesg
> -chgrp adm /var/log/dmesg || :
> +update_logfile_perms
>  elif [ -c /dev/klog ]
>  then
>  [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
>  dd if=/dev/klog of=/var/log/dmesg &
>  sleep 1
>  kill $!
> -[ -f /var/log/dmesg ] && { chgrp adm /var/log/dmesg || : ; }
> +[ -f /var/log/dmesg ] && update_logfile_perms
>  fi
>  }
>
>
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Dmitry Bogatov]

control: tags -1 +moreinfo
control: user kact...@gnu.org
control: usertags -1 objections

[2019-02-04 07:58] Pierre Ynard 
> > Why are you skeptical? I do not see, how syncing /var/log/dmesg
> > permissions with kernel.dmesg_restrict could break things. Or am I
> > missing something?
>
> Well, /var/log/dmesg only covers bootup kernel logs, so maybe some admin
> set it up for unprivileged use of bootup logs, but still wants kernel
> logs in general and after bootup to be restricted, to help deter local
> exploits for example.
>
> /var/log/kern.log permissions don't depend on kernel.dmesg_restrict.
> Also rsyslog seems to capture to kern.log just as many early logs as
> /var/log/dmesg?

While this is defintely interesting question, let us focus on what we
can control -- initscripts.

> /var/log/dmesg isn't the only log file whose permissions are set in that
> brittle way in postinst. Others are /var/log/fsck/{checkroot,checkfs}
> (the two logsave ones), and /var/log/boot (bootlogd). The same logic
> applies so it could make sense to change these too. Or any others making
> use of logsave like was suggested in #901289. Except that there isn't a
> relevant sysctl variable for those.
>
> The way I look at it is as a whole, how initscripts provides logging
> functionality outside of syslog while it may not be available or suited,
> and how to manage that and log permissions. I agree that looking
> at kernel.dmesg_restrict can be a cool tradeoff, but that's very
> specialized.

Thank you for your explanation. Let me sum it up. We have following options:

 * sync permissions of `kernel.dmesg_restrict' and /var/log/dmesg, leave
   other log files (/var/log/boot, ...) as-is

 * enforce permissions of all log files (dmsg, boot, ...) to specific
   value 640 root:adm.

 * sync permissions of all log files (dmsg, boot, ...) to
   `kernel.dmesg_restrict'

 * status-quo, when permissions are set in postinst, but are not enforced
   by initscripts.

As I understand situation, I favor second option. So question is would
anybody be unhappy, if initscripts will override manual `chown/chmod' on
logs, created by initscripts.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Javier M DAW]

Would the attached patch do the trick? (/etc/init.d/bootlogs)

--- a2019-02-04 11:01:02.0 +0100
+++ b2019-02-04 11:03:45.0 +0100
@@ -15,20 +15,62 @@
 [ "$DELAYLOGIN" ] || DELAYLOGIN=yes
 . /lib/init/vars.sh

+# Source options
+if [ -f /etc/default/bootlogs ]
+then
+. /etc/default/bootlogs
+fi
+[ "$LOGFILE_GROUP" ] || LOGFILE_GROUP="adm"
+[ "$LOGFILE_MODE" ] || LOGFILE_MODE="640"
+[ "$OBEY_DMESG_RESTRICT" ] || OBEY_DMESG_RESTRICT=no
+[ "$LOGFILE_RESTRICT_MODE" ] || LOGFILE_RESTRICT_MODE="640"
+
+check_dmesg_restrict()
+{
+if [ `uname -s` = Linux ]
+then
+if which sysctl > /dev/null 2>&1
+then
+DMESG_RESTRICT=`sysctl -n kernel.dmesg_restrict`
+else
+DMESG_RESTRICT=`cat /proc/sys/kernel/dmesg_restrict`
+fi
+fi
+
+}
+
+update_logfile_perms () {
+if  [ "$OBEY_DMESG_RESTRICT" = yes ]
+then
+check_dmesg_restrict
+if [ "$DMESG_RESTRICT" = 1 ]
+then
+TARGET_MODE="$LOGFILE_RESTRICT_MODE"
+else
+TARGET_MODE="$LOGFILE_MODE"
+fi
+else
+TARGET_MODE="$LOGFILE_MODE"
+fi
+
+chmod "$TARGET_MODE" /var/log/dmesg || :
+chgrp "$LOGFILE_GROUP" /var/log/dmesg || :
+}
+
 do_start () {
 # Save kernel messages in /var/log/dmesg
 if which dmesg >/dev/null 2>&1
 then
 [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
 dmesg -s 524288 > /var/log/dmesg
-chgrp adm /var/log/dmesg || :
+update_logfile_perms
 elif [ -c /dev/klog ]
 then
 [ -f /var/log/dmesg ] && savelog -q -p -c 5 /var/log/dmesg
 dd if=/dev/klog of=/var/log/dmesg &
 sleep 1
 kill $!
-[ -f /var/log/dmesg ] && { chgrp adm /var/log/dmesg || : ; }
+[ -f /var/log/dmesg ] && update_logfile_perms
 fi
 }

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Pierre Ynard]

> Why are you skeptical? I do not see, how syncing /var/log/dmesg
> permissions with kernel.dmesg_restrict could break things. Or am I
> missing something?

Well, /var/log/dmesg only covers bootup kernel logs, so maybe some admin
set it up for unprivileged use of bootup logs, but still wants kernel
logs in general and after bootup to be restricted, to help deter local
exploits for example.

/var/log/kern.log permissions don't depend on kernel.dmesg_restrict.
Also rsyslog seems to capture to kern.log just as many early logs as
/var/log/dmesg ?

So it seems to me like introducing a behavior that's variable on a
sysctl parameter doesn't really rationalize things.

Either way, considering the original cause of the bug here, setting log
permissions once in postinst is probably too brittle, confusing and
error-prone. It seems better to set them when the logs are written and
rotated in /etc/init.d/bootlogs; whatever default permissions are used,
that's something that admins can better understand and edit too.

/var/log/dmesg isn't the only log file whose permissions are set in that
brittle way in postinst. Others are /var/log/fsck/{checkroot,checkfs}
(the two logsave ones), and /var/log/boot (bootlogd). The same logic
applies so it could make sense to change these too. Or any others making
use of logsave like was suggested in #901289. Except that there isn't a
relevant sysctl variable for those.

The way I look at it is as a whole, how initscripts provides logging
functionality outside of syslog while it may not be available or suited,
and how to manage that and log permissions. I agree that looking
at kernel.dmesg_restrict can be a cool tradeoff, but that's very
specialized.

-- 
Pierre Ynard

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Dmitry Bogatov]

control: tags -1 +moreinfo
control: forcemerge -1 570358

[2019-01-24 10:17] Pierre Ynard 
>
> part   text/plain 742
> > Interesting. On my system `/var/log/dmesg' is 640, root:adm, which is
> > quite restrictive. If I run `/etc/init.d/bootlogs' again, it stays so.
> >
> > But if I remove `/var/log/dmesg' and re-run `/etc/init.d/bootlogs',
> > `/var/log/dmesg' becomes 644.
> >
> > I believe adjustment to `/etc/init.d/bootlogs' to check
> > `kernel.dmesg_restrict' is needed. By the way, any ideas how could I
> > have 640 `/var/log/dmesg' in first place?
>
> initscripts's postinst script sets the permissions to 640 if the file
> doesn't exist.
>
> Setting /var/log/dmesg permissions according to kernel.dmesg_restrict
> seems to make sense but I'm a bit skeptical. I suppose that the way it
> keeps permissions set on it by the admin is both a bug and a feature.

Why are you skeptical? I do not see, how syncing /var/log/dmesg
permissions with kernel.dmesg_restrict could break things. Or am I
missing something?

Merging with #570358, since resolution to this bug would imply
resolution to #570358.

-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Pierre Ynard]

> Interesting. On my system `/var/log/dmesg' is 640, root:adm, which is
> quite restrictive. If I run `/etc/init.d/bootlogs' again, it stays so.
>
> But if I remove `/var/log/dmesg' and re-run `/etc/init.d/bootlogs',
> `/var/log/dmesg' becomes 644.
>
> I believe adjustment to `/etc/init.d/bootlogs' to check
> `kernel.dmesg_restrict' is needed. By the way, any ideas how could I
> have 640 `/var/log/dmesg' in first place?

initscripts's postinst script sets the permissions to 640 if the file
doesn't exist.

Setting /var/log/dmesg permissions according to kernel.dmesg_restrict
seems to make sense but I'm a bit skeptical. I suppose that the way it
keeps permissions set on it by the admin is both a bug and a feature.

-- 
Pierre Ynard

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[Michael Biebl]

That file is not written by rsyslog so this bug was misfiled

> Am 09.07.2017 um 10:06 schrieb mv87 :
> 
> Package: rsyslog
> Version: 8.24.0-1
> Severity: normal
> Tags: security
> 
> According to https://wiki.debian.org/NewInStretch 'dmesg' should require
> superuser privileges.
> /var/log/dmesg is world-readable which might undermine the restriction set by
> kernel.dmesg_restrict = 1.
> 
> 
> 
> -- System Information:
> Debian Release: 9.0
>  APT prefers stable
>  APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
> LANGUAGE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages rsyslog depends on:
> ii  init-system-helpers  1.48
> ii  libc62.24-11+deb9u1
> ii  libestr0 0.1.10-2
> ii  libfastjson4 0.99.4-1
> ii  liblogging-stdlog0   1.0.5-2+b2
> ii  liblognorm5  2.0.1-1.1+b1
> ii  libsystemd0  232-25
> ii  libuuid1 2.29.2-1
> ii  lsb-base 9.20161125
> ii  zlib1g   1:1.2.8.dfsg-5
> 
> Versions of packages rsyslog recommends:
> ii  logrotate  3.11.0-0.1
> 
> Versions of packages rsyslog suggests:
> pn  rsyslog-doc
> pn  rsyslog-gnutls 
> pn  rsyslog-gssapi 
> pn  rsyslog-mongodb
> pn  rsyslog-mysql | rsyslog-pgsql  
> pn  rsyslog-relp   
> 
> -- no debconf information

Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1

[mv87]

Package: rsyslog
Version: 8.24.0-1
Severity: normal
Tags: security

According to https://wiki.debian.org/NewInStretch 'dmesg' should require
superuser privileges.
/var/log/dmesg is world-readable which might undermine the restriction set by
kernel.dmesg_restrict = 1.



-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rsyslog depends on:
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u1
ii  libestr0 0.1.10-2
ii  libfastjson4 0.99.4-1
ii  liblogging-stdlog0   1.0.5-2+b2
ii  liblognorm5  2.0.1-1.1+b1
ii  libsystemd0  232-25
ii  libuuid1 2.29.2-1
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages rsyslog recommends:
ii  logrotate  3.11.0-0.1

Versions of packages rsyslog suggests:
pn  rsyslog-doc
pn  rsyslog-gnutls 
pn  rsyslog-gssapi 
pn  rsyslog-mongodb
pn  rsyslog-mysql | rsyslog-pgsql  
pn  rsyslog-relp   

-- no debconf information