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
| ||
|
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/
Powered by blists - more mailing lists