Re: syscall convention

dwheelerat_private

On Aug 21,  3:48pm, Crispin Cowan wrote:

> At the DC LSM BOF, the group consensus was that there would be no IANA for
> module numbers, but we would add one additional int (or unsigned, I forget)
> argument to the LSM syscall.

Yes.  I think this convention's consistent with that.

>  Individual "vendors" (loosely defined) that want
> to multiplex multiple modules...
> can use the argument to do so, and arbitrary consortia of projects (e.g.
> SELinux and SGI) can make up ad hoc methods of partitioning the space of ints
> so as to assign unique IDs to individual modules.

The trouble with the "ad hoc" methods is that they require coordination.
Even if you're coordinating, one less issue to coordinate about is a
Good Thing (TM).  And when A and B coordinate, they often don't include C,
who joined A and B later.  Best to auto-coordinate, where possible.

> David's suggestion for a method to assign module IDs is a good one, and
> consortia who want to cooperate should consider using it.  An alternative
> suggestion is to assign each vendor a range of numbers, similar to the way
that
> Ethernet MAC addresses are managed.

Yes, but the MAC approach requires IANA-like coordination, which everyone
agreed was to be avoided.  Ranges stink anyway.. you always have too many
numbers or too few.

> But we probably shouldn't enforce such a convention in code: too many people
> feel too strongly that the whole IANA thing is broken, so the extra argument
is
> just provided for people who want it for "something"...

I agree that it shouldn't be enforced by the kernel itself...
which is why I simply suggested it as a convention, rather than as something
to be enforced. (My text said "if every module being stacked
obeyed the convention"... no need for the "if" if it's enforced at the kernel).

The IANA approach is broken because of the problems of distributed
coordination. By recommending hashes, we sidestep the problem entirely.

Richard Offer said:
>I will submit a patch that adds an extra parameter to syscall
>    sys_security(int modid, int cmd, unsigned long *args)

Could we include documentation on this parameter somewhere
(at least in a comment)?  Here's some starter documentation:

  The "modid" parameter identifies the security module, to support safety
 checking and "stacking" of multiple modules.  Not all security
 modules care about the modid parameter value or follow the usual
 conventions; see the security module's
 documentation for more information.  By convention, the modid value
 usually has the first 32 bits of the module name's MD5 hash, computed as:
   echo -n 'MODULE_NAME' | md5sum | head --bytes=8; echo
 Thus, the "world-domination" security module's modid is usually 0x95189e78.
 This approach eliminates the need for a central registry, supports safety
 and stacking, and retains the speed of a system call.

I've no doubt that the people on this list will comment about this text :-).

By the way, I've thought of ANOTHER reason to use this "modid" parameter:
aiding static checking tools.  I use tools that analyze entire
distributions.  Calls like sys_security(1, "hello") are a mystery,
because I may not know what module is intended.
I have a much better shot at analyzing
sys_security(MAGIC_SELINUX, 1, "hello"), because key information is
now statically (and easily) available.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module