linux-kernel - Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

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: <480EE1F6.3070205@ak.jp.nec.com>
Date:	Wed, 23 Apr 2008 16:15:02 +0900
From:	KaiGai Kohei <kaigai@...jp.nec.com>
To:	Chris Wright <chrisw@...s-sol.org>
CC:	greg@...ah.com, morgan@...nel.org, serue@...ibm.com,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] exporting capability name/code pairs (for 2.6.26)

Chris Wright wrote:
> * KaiGai Kohei (kaigai@...jp.nec.com) wrote:
>> [PATCH 2/3] exporting capability name/code pairs
>>
>> This patch enables to export code/name pairs of capabilities the running
>> kernel supported.
>>
>> A newer kernel sometimes adds new capabilities, like CAP_MAC_ADMIN
>> at 2.6.25. However, we have no interface to disclose what capabilities
>> are supported on the running kernel. Thus, we have to maintain libcap
>> version in appropriate one synchronously.
>>
>> This patch enables libcap to collect the list of capabilities at run time,
>> and provide them for users. It helps to improve portability of library.
>>
>> It exports these information as regular files under /sys/kernel/capability.
>> The numeric node exports its name, the symbolic node exports its code.
> 
> I do not understand why this is necessary.  The capability bits are an ABI
> that shouldn't change in a non-backward compat way (i.e. only additions).
> 
> We typically don't export strings <-> number conversions for constants.
> I know you've explained this a few times before, but it still seems to me
> like a userspace only problem.  What can userspace do with a capability
> it does not know about?

When we run a userspace utility on the latest kernel, it has to be compiled
with kernel-headers which have same capability set at least.
If installed userspace utility does not support newly added capabilities,
it requires users to rebuild their utilities when they update the kernel.

Typically, kernel developer faces this kind of version mismatching.
When they boots their kernel with new capabilities, it also requires to
rebuild libcap. Then, they have to revert it, when they boots with normal
kernel.

If libcap can know what capabilities are supported on the running kernel
automatically, it does not need users to rebuild libcap concurrently.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@...jp.nec.com>
--
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/