linux-kernel - Re: CAP_SYSLOG, 2.6.38 and user space

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]

Message-ID: <1296748401.14846.39.camel@moria>
Date:	Thu, 03 Feb 2011 16:53:21 +0100
From:	Gergely Nagy <algernon@...abit.hu>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>
Subject: Re: CAP_SYSLOG, 2.6.38 and user space

On Thu, 2011-02-03 at 15:32 +0000, Serge E. Hallyn wrote:
> > Back in november, a patch was merged into the kernel (in  commit
> > ce6ada35bdf710d16582cc4869c26722547e6f11), that splits CAP_SYSLOG out of
> > CAP_SYS_ADMIN.
> > 
> > Sadly, this has an unwelcomed consequence, that any userspace syslogd
> > that formerly used CAP_SYS_ADMIN will stop working, unless upgraded, or
> > otherwise adapted to the change.
> > 
> > However, updating userspace isn't that easy, either, if one wants to
> > support multiple kernels with the same userspace binary: pre-2.6.38, one
> > needs CAP_SYS_ADMIN, but later kernels will need CAP_SYS_ADMIN. It would
> > be trivial to keep both, but that kind of defeats the purpose of
> > CAP_SYSLOG,
> 
> The idea would be to only use both when you detect a possibly older
> kernel. 

I was considering that, but... how do I reliably detect an older kernel?

So far, I didn't find a reliable way with which I can detect a kernel
version at run-time (apart from parsing utsname) - but it's entirely
possible, that I missed something obvious.

Furthermore, this still needs an userspace upgrade aswell, so only helps
one half of the problem.

> However, you're right of course, I really should have provided some way
> for userspace to click 'ok, got the message, now continue anyway because
> I'm running older userspace for now,'  i.e. a sysctl perhaps.
> 
> Sorry about the trouble.  Here is a patch to just warn for now, with
> the changelog showing what i intend to push next.
> 
> sorry again,
> -serge
> 
> From 2d7408541dd3a6e19a4265b028233789be6a40f4 Mon Sep 17 00:00:00 2001
> From: Serge Hallyn <serge@....(none)>
> Date: Thu, 3 Feb 2011 09:26:15 -0600
> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now
> 
> At 2.6.39 or 2.6.40, let's add a sysctl which defaults to 0.  When
> 0, refuse if cap_sys_admin, if 1, then allow.  This will allow
> users to acknowledge (permanently, if they must, using /etc/sysctl.conf)
> that they've seen the syslog message about cap_sys_admin being
> deprecated for syslog.

Could we have it the other way around, at least for a while? Otherwise,
if someone happens to upgrade the kernel, and forgets to upgrade the
syslogd, he'll still experience breakage. With defaulting to 1,
compatiblity is kept, and systems that were upgraded properly can set it
to 0 and live happily ever after. The WARNs should prompt people to
upgrade at the first opportunity, so hopefully, it won't go unnoticed
and ignored by userspace.

I'm not sure one would even see the kernel warn with the syslogd not
being able to read the kernel messages (dmesg, of course, would reveal
it, but that's one extra step).

-- 
|8]


--
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/