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, 09 Feb 2011 23:37:19 +0100
From:	Gergely Nagy <algernon@...abit.hu>
To:	david@...g.hm
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

> what's wrong with doing a runtime test at startup that tries to read with 
> CAP_SYS_ADMIN and if you get -EPERM trying again with CAP_SYSLOG?

That's also an option I considered, and might end up doing if there's no
easier option.  In my case, though, due to the design of the code, it's
not trivially simple to do that (it isn't particularly hard, either, but
such a test wouldn't be my first choice).

> creating an ioctl for something like this seems like it's significantly 
> overcomplicating the issue.

True.

Nevertheless, like I said before: my main concern is making sure
userspace doesn't break. Figuring out how to support CAP_SYSLOG best is
a much lower priority on my list, and I haven't given it all that much
thought.

I'd prefer an ioctl or something similar which I can easily query,
without having to resort to trial and error or version sniffing. But I
understand that's not the best option from a kernel PoV, so falling back
to trying to read at startup is an acceptable solution aswell.

So, yeah... I suppose simply introducing CAP_SYSLOG, and keeping
CAP_SYS_ADMIN as it is would work just fine.

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