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: <20110204080302.GA24941@marc.osknowledge.org>
Date:	Fri, 4 Feb 2011 09:03:14 +0100
From:	Marc Koschewski <marc@...nowledge.org>
To:	david@...g.hm
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Gergely Nagy <algernon@...abit.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James Morris <jmorris@...ei.org>
Subject: Re: CAP_SYSLOG, 2.6.38 and user space

Hey,


* david@...g.hm <david@...g.hm> [2011-02-03 16:49:08 -0800]:

> On Thu, 3 Feb 2011, Serge E. Hallyn wrote:
> 
> >Quoting Gergely Nagy (algernon@...abit.hu):
> >>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)
> >
> >...  Why not parse utsname?
> 
> because the name may be different on different systems, a generic software
> package is not going to be able to interpret them all.
> 
> >>>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,
> >
> >Sure.
> >
> >So long as there is a definite path toward eventually having syslog
> >with CAP_SYS_ADMIN be denied.
> 
> I can see what you would want to allow for a syslog daemon to have
> CAP_SYSLOG without needing to have CAP_SYS_ADMIN, but why do you see it as
> important to deny the ability if someone has CAP_SYS_ADMIN?

ack++

Moreover, this change really is 'hell' on _many_ machines. We had discussed a
thousands time to not break existing applications. So a) either make it optional in
the kernel so that userspace still works with CAP_SYS_ADMIN _and_ CAP_SYSLOG
while dropping a note that it should be fixed in userspace _and_ mark it as
deprecated as of mid 2012 or b) revert it.

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

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