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: <482A7F64.50705@ak.jp.nec.com>
Date:	Wed, 14 May 2008 14:57:56 +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:
>> Chris, what is the status of the patch?
> 
> I still don't understand how ...

Hmm...

>>> 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.
> 
> ...libcap can do anything meaningful here with capabilities it doesn't
> know about?  This interface is already versioned, what is wrong is old
> cap version on new kernel (clearly new cap version on old kernel would
> have to fall back to older cap version)?

The versioning info is just a hint in this case.

The major purpose of this patch is to save steps of maintainance.
When we tries to run a application using a new capability provided by
the latest kernel, we have to rebuild libcap to follow kernel updates.

If we can obtain an information what capabilities are supported in
the running kernel, we don't need to rebuild libcap for the latest
kernel everytime.

For example, we got CAP_MAC_ADMIN at 2.6.25. If an application tries to
use it, we have to replace libcap for 2.6.24 by libcap for 2.6.25.
Although, we don't get any updates in libcap. :-(

In addition, I noticed it will be usefull for applications which have
a possibility to use arbitary number of capabilities, like busybox
if setcap/getcap stuff is ported.
(IMO, we should not use libcap for busybox, because its first priority
  is to reduce binary size, limited to minimun functionalities.)

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/