linux-kernel - Re: [PATCH] Exporting capability code/name pairs

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: <477455A0.7060603@ak.jp.nec.com>
Date:	Fri, 28 Dec 2007 10:47:12 +0900
From:	KaiGai Kohei <kaigai@...jp.nec.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
CC:	akpm@...l.org, morgan@...nel.org,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Exporting capability code/name pairs

Serge E. Hallyn wrote:
> Quoting KaiGai Kohei (kaigai@...jp.nec.com):
>> This patch enables to export the code/name pairs of capabilities under
>> /capability of securityfs.
>>
>> In the current libcap, it obtains the list of capabilities from header file
>> on the build environment statically. However, it is not enough portable
>> between different versions of kernels, because an already built libcap
>> cannot have knowledge about new added capabilities.
>>
>> Dynamic collection of code/name pairs of capabilities will resolve this
>> matter.
>>
>> But it is not perfect one. I have a bit concern about this patch now.
>>
>> 1. I want to generate cap_entries array from linux/capability.h
>>    automatically. Is there any good idea?
>> 2. We have to mount securityfs explicitly, or using /etc/fstab.
>>    It can make a matter when we want to use this features
>>    in very early boot sequence.
>>
>> Any comment please.
> 
> I like the idea, but
   - snip -
>> +/*
>> + * capability code/name pairs are exported under /sys/security/capability/
>> + */
>> +struct cap_entry_data {
>> +	unsigned int code;
>> +	const char *name;
>> +};
>> +
>> +static struct cap_entry_data cap_entries[] = {
>> +	/* max number of supported format */
>> +	{ _LINUX_CAPABILITY_VERSION,	"version" },
>> +	/* max number of capability */
>> +	{ CAP_LAST_CAP,			"index" },
>> +	/* list of capabilities */
>> +	{ CAP_CHOWN,			"cap_chown" },
>> +	{ CAP_DAC_OVERRIDE,		"cap_dac_override" },
   - snip -
>> +	{ CAP_MAC_OVERRIDE,		"cap_mac_override" },
>> +	{ CAP_MAC_ADMIN,		"cap_mac_admin" },
>> +	{ -1,				NULL},
>> +};
> 
> I don't like this duplication with the list in include/linux/capability.h.
> Now when a new cap is added, it needs to be
> 
> 	1. added to capability.h
> 	2. swapped as the new CAP_LAST_CAP in capability.h
> 	3. added to this list...
> 
> Could you integrate the two lists (not sure how offhand), or at least
> put them in the same place?

The following script will generate cap_entries[] array.

cat include/linux/capability.h				\
  | egrep '^#define[ \t]+CAP_[A-Z_]+[ \t]+[0-9]+$'	\
  | awk '{ printf("\t{ %s, \"\" },\n", $2, tolower($2)); }'

It is nice to include the result of this script, like as:

static struct cap_entry_data cap_entries[] = {
	/* max number of supported format */
	{ _LINUX_CAPABILITY_VERSION,	"version" },
	/* max number of capability */
	{ CAP_LAST_CAP,			"index" },
#include "capability_names.h"
	{ -1,				NULL },
};

I guess we can put this script on Makefile like as kernel/timeconst.pl doing.

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/