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: <200711070411.lA74Bdvn041341@www262.sakura.ne.jp>
Date:	Wed, 07 Nov 2007 13:11:39 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:	casey@...aufler-ca.com
Cc:	crispin@...spincowan.com, simon@...e.lp0.eu,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, cliffe@...net,
	oiaohm@...il.com
Subject: Re: Defense in depth: LSM *modules*, not a static interface

Hello.

Casey Schaufler wrote:
> Fine grained capabilities are a bonus, and there are lots of
> people who think that it would be really nifty if there were a
> separate capability for each "if" in the kernel. I personally
> don't see need for more than about 20. That is a matter of taste.
> DG/UX ended up with 330 and I say that's too many.

TOMOYO Linux has own (non-POSIX) capability that can support 65536 capabilities
if there *were* a separate capability for each "if" in the kernel.
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.1.x/tomoyo-lsm/patches/tomoyo-capability.diff?root=tomoyo&view=markup

The reason I don't use POSIX capability is that the maximum types are limited to
bitwidth of a variable (i.e. currently 32, or are we going to extend it to 64).
This leads to abuse of CAP_SYS_ADMIN capability.
In other words, it makes fine-grained privilege division impossible.

Since security_capable() cannot receive fine-grained values,
TOMOYO can't do fine-grained privilege division.

I wish if capability machanism has mapping layer like:

#define CAP_DIVIDED_FOO1 0
#define CAP_DIVIDED_FOO2 1
#define CAP_DIVIDED_FOO3 2
  ...
#define CAP_DIVIDED_BAR1 100
#define CAP_DIVIDED_BAR2 101
#define CAP_DIVIDED_BAR3 102

const int cap_divided_to_grouped(int cap_divided)
{
	static const int cap_mapping_array[] = {
		/* [divided index value] = POSIX compatible index value (i.e. 0-31) */
		[CAP_DIVIDED_FOO1] = 0,
		[CAP_DIVIDED_FOO2] = 0,
		[CAP_DIVIDED_FOO3] = 0,
		[CAP_DIVIDED_BAR1] = 1,
		[CAP_DIVIDED_BAR2] = 1,
		[CAP_DIVIDED_BAR3] = 1,
	};
	return cap_mapping_array[cap_divided];
}

int capable(int cap_divided)
{
	return security_capable(cap_divided);
}

int security_capable(int cap_divided)
{
	/* Allow LSM to decide based on fine-grained capability index. */
	return LSM_implementation_specific_capability_check(cap_divided_to_grouped(cap_divided));
}

int function_foo(void)
{
	if (!capable(CAP_DIVIDED_FOO1))
		return -EPERM;
	return 0;
}

int function_bar(void)
{
	if (!capable(CAP_DIVIDED_BAR2))
		return -EPERM;
	return 0;
}

Thanks.
-
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