File descriptors: LSM should support them in phase 1.

dwheelerat_private

Crispin Cowan <crispinat_private> said:
>Ok.  I'm convinced of the validity of fd's for audit purposes.  I'm further
>convinced that it would be hard to reconstruct the fd's from other provided
>information.
>What I'm not convinced of is that this needs to go into phase 1.

I believe fd support _does_ need to be added, in phase 1, to reduce later
"API shuffling".

There appears to be an understanding that there _will_ be a phase 2 which
will add audit, and an increasing consensus that fd's will have to be added.
If the current hooks don't include fd's, then in phase 2
EVERYONE (including those who DON'T need fd's) will have to change
their modules, in a large variety of locations.

We can't forsee all possible changes in the future, but here's a case
where the need appears to be known.   Let's do it right the first time.

At the user API level this happens all the time - some arguments aren't
used YET, but they're there so that planned changes can occur without
harming user applications.  In theory this is less critical for
kernel modules (APIs _do_ change for them more often!), but even there,
module interface changes are often a cause of anguish.

It's not clear that the kernel developers will really see including the
fd's as significant additional complexity -- it requires very little
additional information in each hook call.

As for how to argue this with the kernel developers, how about this:
"Many hooks pass the file descriptors (fds), because it's impractical to
derive this information in other ways, and some functions (particularly
some advanced auditing & intrusion detection systems) require this
information.  In this phase we haven't added all hooks necessary for
some auditing features, but we've designed this interface
to ease adding them later."

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