Re: [PATCH 1/3] Make cap default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jul 03, 2005 at 05:43:33PM +0200, Kurt Garloff wrote:

> Note that we could think of getting rid of dummy; however, it's
> still used as fallback for stubs that are not implemented by an
> LSM. I did not want to change this with this patch set, though
> I'd like to see it done if everyone agrees it's a good idea.

I think this needs to happen (dummy goes away or it's contents are replaced
by cap routines as appropriate).

Currently in security_init() verify(&dummy_security_ops) calling 
security_fixup_ops is a no-op in terms of modifying dummy. In your patch as
you suggest verify(&capability_security_ops) now patches routines from dummy 
into this default capability_security_ops.  The code is already too baroque,
no point making it more complex.

I think the necessary functions need to be present in this new base structure
and security_fixup_ops patches from it into whatever new ops a caller passes, 
dummy goes away. As a bonus, at this point your capability_ops struct in
capability.c can really be different :-)

--- linux-2.6.10.orig/security/commoncap.c
+++ linux-2.6.10/security/commoncap.c
[snip]
> +EXPORT_SYMBOL(capability_security_ops);
> +/* Note: If the capability security module is loaded, we do NOT register
> + * the capability_security_ops but a second structure that has the
> + * identical entries. The reason is that this way,
> + * - we could stack on top of capability if it was stackable
> + * - a loaded capability module will prevent others to register, which
> + *   is the previous behaviour; if capabilities are used as default (not
> + *   because the module has been loaded), we allow the replacement.
> + */
> +#endif

The intent here is to make it past the 
	if (security_ops != &capability_security_ops)
check in security.c::register_security so that it is possible to actually
register capability (capability_ops) subsequently as a module should you
so desire, no?

The above description doesn't impart that.  Plus why would you want to stack
capability on top of this base capability, even if it it supported stacking?

--- linux-2.6.10.orig/security/capability.c
+++ linux-2.6.10/security/capability.c

+/* Note: If the capability security module is loaded, we do NOT register
+ * the capability_security_ops but a second structure capability_ops
+ * that has the identical entries. The reasons:
+ * - we could stack on top of capability if it was stackable
+ * - a loaded capability module will prevent others to register, which
+ *   is the previous behaviour; if capabilities are used as default (not
+ *   because the module has been loaded), we allow the replacement.

Ditto for this comment.

>  static int __init capability_init (void)
>  {
> +	memcpy(&capability_ops, &capability_security_ops, sizeof(capability_ops));
>  	if (capability_disable) {
>  		printk(KERN_INFO "Capabilities disabled at initialization\n");
>  		return 0;
>  	}

No point doing the memcpy if capability_disable is true.

Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux