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:	Fri, 28 Dec 2007 20:12:32 +1100 (EST)
From:	James Morris <jmorris@...ei.org>
To:	KaiGai Kohei <kaigai@...jp.nec.com>
cc:	"Serge E. Hallyn" <serue@...ibm.com>, 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

On Fri, 28 Dec 2007, KaiGai Kohei wrote:

> Remaining issues:
> - We have to mount securityfs explicitly, or use /etc/fstab.
>   It can cause a matter when we want to use this feature on
>   very early phase on boot. (like /sbin/init)

Why can't early userspace itself mount securityfs?

I'm not even sure this is a good idea at all.  Existing capabilities will 
never disappear, and, as with syscalls, it's probably up to userland to 
handle new ones not existing.

In any case, some more technical issues:

> kernel/cap_names.sh generates the body of cap_entries[] array,

This needs to be in the scripts directory.

The generated header should be made idempotent (#ifdef wrapping), and also 
include a warning that it is automatically generated (identifying the 
script which does so), and that is should not be edited.

> +	d_caps = securityfs_create_dir("capability", NULL);
> +	if (!d_caps)

Wrong way to check for error -- the function returns an ERR_PTR().

> +		f_caps[i] = securityfs_create_file(cap_entries[i].name, 0444,
> +						   d_caps, &cap_entries[i],
> +						   &cap_entry_fops);
> +		if (!f_caps[i])

Ditto.

Another issue is that securityfs depends on CONFIG_SECURITY, which might 
be undesirable, given that capabilities are a standard feature.


- James
-- 
James Morris
<jmorris@...ei.org>
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ