linux-kernel - Re: [PATCH v2] kmsg: Honor dmesg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Apr 2013 17:51:03 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Kees Cook <keescook@...omium.org>
Cc:	Kay Sievers <kay@...y.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Eric Paris <eparis@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christian Kujau <lists@...dbynature.de>,
	"# 3.4.x" <stable@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, kzak@...hat.com
Subject: Re: [PATCH v2] kmsg: Honor dmesg_restrict sysctl on /dev/kmsg

On Wed, Apr 24, 2013 at 02:36:39PM -0700, Kees Cook wrote:
> >>
> >> So, the problem here is the expectation of privileges. The /proc/kmsg
> >> usage pattern was:
> >>
> >> open /proc/kmsg with CAP_SYSLOG
> >> drop CAP_SYSLOG
> >> read /proc/kmsg forever
> >
> > This doesn't change the /proc interface at all.
> 
> Right, I meant that Kay's assertion that /proc/kmsg is "legacy" means
> he expects syslog daemons to switch to using /dev/kmsg.
> 
> >> If we change the FILE vs CALL and OPEN vs READ stuff here, we're lying
> >> to the API about what's happening. If we use this patch, then we can't
> >> use /dev/kmsg in the same way (i.e. running without privileges).
> >
> > Uh... Yes we can.  I tested it as a normal user.  It works just fine
> > running without privs and without CAP_SYSLOG, like it did before there
> > was a patch at all.  It also honors dmesg_restrict in devkmsg_read.
> > I'm confused why you think this doesn't work?
> 
> I don't think I was clear. There are two use-cases, as I see it:
> 
> - normal user running dmesg(1)
> - system daemon pulling kernel syslog and putting into userspace (e.g.
> /var/log/kern.log).

Ah.

> In the dmesg(1) case, we're fine. It was using syscalls, now it can
> use /dev/kmsg since open isn't checked, just the read action. That's
> all cool by me.

OK.

> In the daemon case, it's nice to be able to drop privileges after
> setting up resources. The past was open /proc/kmsg with CAP_SYS_ADMIN,
> then drop CAP_SYS_ADMIN and keep reading. Then later CAP_SYS_LOG was
> introduced. So if a daemon switched from /proc/kmsg to /dev/kmsg they
> wouldn't be able to drop the capability. But, it's much saner to carry
> CAP_SYS_LOG than CAP_SYS_ADMIN on a long-running daemon.

I have no idea on this front.  I'll let Kay speak to that.  On my
currently running Fedora 18 system, I actually have systemd-journald
using /dev/kmsg, and rsyslog using /proc/kmsg.  Why I have both, I have
no friggin idea.
 
> >> That said, I much prefer doing the privilege test at read time since
> >> that means passing a file descriptor to another process doesn't mean
> >> the new process can just continue reading. If we're going to be
> >> defining the new behavior for /dev/kmsg, then I think we should
> >> explicitly drop the fall-back to CAP_SYS_ADMIN. Perhaps introduce a
> >
> > I think Karel and Kay's entire point was /dev/kmsg shouldn't be getting
> > new behavior.  Aside from honoring dmesg_restrict, they see any behavior
> > change as a regression.
> 
> Is there an intention to use /dev/kmsg for the syslog management daemon?

Maybe?  I mean, systemd-journald seems to be using it for something.
Kay?

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/