linux-kernel - Re: [PATCH v13 0/9] LSM: Multiple concurrent LSMs

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:	Thu, 25 Apr 2013 23:16:23 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	casey@...aufler-ca.com, john.johansen@...onical.com
Cc:	paul@...l-moore.com, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	jmorris@...ei.org, eparis@...hat.com, keescook@...omium.org
Subject: Re: [PATCH v13 0/9] LSM: Multiple concurrent LSMs

Casey Schaufler wrote:
> >> I'm still in favor of assigning the network hooks to the LSM at boot based on 
> >> the "security=" configuration.
> >>
> > yeah dealing with selection at boot time is going to be needed
> > at some point, whether its now or later ...
> 
> I'll have a go at it then. What that would mean is that:
> 
> 	security=smack,selinux
> 
> gives Smack NetLabel and SELinux xfrm and secmark while
> 
> 	security=selinux,smack
> 
> gives SELinux all three. I would still like it to be possible to
> explicitly configure the allocation at build time.

The problem is that it is difficult to control the registration order since
each LSM module directly calls security_initcall() for registering themselves?

Then, what about replacing

  static int __init foo_init()
  {
    register_security(&foo_security_ops);
    return 0;
  }
  security_initcall(foo_init);

  static int __init bar_init()
  {
    register_security(&bar_security_ops);
    return 0;
  }
  security_initcall(bar_init);

with

  static int __init foo_init()
  {
    register_security(&foo_security_ops);
    return 0;
  }

  static int __init bar_init()
  {
    register_security(&bar_security_ops);
    return 0;
  }

  static int __init add_foo(void) {
    foo_security_ops.register = foo_init;
    list_add_tail(&foo_security_ops.list[lsm_candidate], &lsm_hooks[lsm_candidate]);
    return 0;
  }
  pure_initcall(add_foo);

  static int __init add_bar(void) {
    bar_security_ops.register = bar_init;
    list_add_tail(&bar_security_ops.list[lsm_candidate], &lsm_hooks[lsm_candidate]);
    return 0;
  }
  pure_initcall(add_bar);

and let security/security.c register in accordance with
security= parameter (or compile-time config if none given)?

  static int __init register_lsms(void)
  {
    for_each_comma_separated_lsm_names_given() {
      bool found = 0;
      list_for_each_entry_safe(ops, tmp, &lsm_hooks[lsm_candidate]) {
        if (!strcmp(ops->name, name)) {
          if (ops->register() == 0)
            list_del(&ops->list[lsm_candidate]);
          found = 1;
          break;
        }
      }
      if (!found) {
        printk("LSM module %s was not found\n", name);
      }
    }
    list_for_each_entry_safe(ops, tmp, &lsm_hooks[lsm_candidate]) {
      list_del(&ops->list[lsm_candidate]);
      printk("LSM module %s was not enabled\n", ops->name);
    }
  }
  security_initcall(register_lsms);

(Well, list_add_tail() in pure_initcall functions should be optimized
 by statically embedding into security/security.c at compile time?)
--
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/