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]

Date:	Wed, 9 Feb 2011 13:47:01 -0800 (PST)
From:	david@...g.hm
To:	Gergely Nagy <algernon@...abit.hu>
cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	James Morris <jmorris@...ei.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: CAP_SYSLOG, 2.6.38 and user space

On Wed, 9 Feb 2011, Gergely Nagy wrote:

> On Wed, 2011-02-09 at 13:34 -0800, david@...g.hm wrote:
>> On Wed, 9 Feb 2011, Gergely Nagy wrote:
>>
>>> On Wed, 2011-02-09 at 21:23 +0000, Serge E. Hallyn wrote:
>>>> So if that's how we're leaning, then the following patch is much more
>>>> concise.  I'll send this to Linus and any appropriate -stable tomorrow
>>>>  if noone objects.
>>>>
>>>> From 5166e114d6a7c508addbadd763322089eb0b02f5 Mon Sep 17 00:00:00 2001
>>>> From: Serge Hallyn <serge@...lyn.com>
>>>> Date: Thu, 3 Feb 2011 09:26:15 -0600
>>>> Subject: [PATCH 1/1] cap_syslog: don't refuse cap_sys_admin for now (v2)
>>>>
>>>> It'd be nice to do that later, but it's not strictly necessary,
>>>> and it'll be hard to do without breaking somebody's userspace.
>>>>
>>>> Signed-off-by: Serge Hallyn <serge@...lyn.com>
>>>> ---
>>>>  kernel/printk.c |   14 ++++----------
>>>>  1 files changed, 4 insertions(+), 10 deletions(-)
>>>
>>> Personally, I'd prefer the sysctl idea in the long run, because
>>> userspace can easily and automatically adapt to the running kernel then.
>>> Ie, this patch is fine for 2.6.38, but later on, a sysctl could be
>>> introduced, that when set (but defaulting to unset, as to not break
>>> userspace), would make CAP_SYS_ADMIN return -EPERM. That way, syslogds
>>> could look at the setting, and act accordingly. This would mean that old
>>> userspace wouldn't break, and upgraded userspace could work on both old
>>> and new kernels, depending on the setting. Distros or admins could then
>>> enable the sysctl once they made sure that all neccessary applications
>>> have been upgraded.
>>
>> what is your justification for ever having CAP_SYS_ADMIN return -EPERM?
>> what's the value in blocking this.
>
> Nothing. Come to think of it, the main use of the sysctl would be to
> detect CAP_SYSLOG support, so that applications can drop CAP_SYS_ADMIN
> and use CAP_SYSLOG only (which, imo, is a good idea - the less
> capabilities, the better, and CAP_SYS_ADMIN is quite broad when one only
> wants CAP_SYSLOG).
>
> If there's a better way to allow userspace to easily detect CAP_SYSLOG,
> I'm all for that.

if userspace wants to detect this, what is wrong with them checking for a 
kernel >= 2.6.38?

realistically, if the upstream applications (which need to work with many 
different versions) just support having CAP_SYS_ADMIN, it would be a very 
minor distro patch to change this to CAP_SYSLOG for a distro release where 
the distro _knows_ that they don't have to support an older kernel.

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/