David Wheeler wrote:
> I think it'd be wiser to in-line this stuff, using code modification.
> This could be done by patching on request, or by inserting NOPs
> and replacing them with code when the hook is active.
>
> The result would have NO or NEARLY NO performance overhead
> for the case where there's no hooked function (a common case even when
> a security module is loaded), and no more performance overhead when it is.
I think that the self-modifying-code approach is likely to bounce, as it
completely breaks on ROM'd systems. With Linux's current momentum into embedded
space, I suspect that self-modifying code would be rejected out of hand.
> * I think allowing multiple security modules is needed. If nothing else,
> it would support breaking security models into smaller composable pieces.
> Also, you might want to implement IDS/audit systems separately from the
> security model, and have them invoked in turn (so they can be
> implemented/maintained separately).
In some form, I agree. Greg seems to have some specific ideas on how to do this.
It seems to be something akin to chaining, where a module that chooses to
cooperate with others can turn around and export interfaces that some other module
would hook to.
> This could be _IMPLEMENTED_ as requiring all nonempty hooks to invoke a
> single "multiplexing module" that then determined how all other modules would
> be called. I think PAM is a reasonable model here -- usually you'd
> want _all_ things to permit, else deny a request, but perhaps you'd want
> one modules "permit" to override. I can even see the possibility of
> having different kinds of "multiplexing modules", giving you different
> ways of combining security modules if you need it.
Under Greg's scheme, each module is the multiplexor for the one down stream. I
can conceive of someone wanting a more hierarchical view, and writing a
multiplexor module for some family of modules. But because security composition
does not generalize, the multiplexor module is likely to remain specific to some
family of modules, rather than becoming completely generic.
> * There needs to be "portable" support for state in various in-memory
> data structures. The obvious one is task_struct (in Linux 2.2, defined in
> /usr/src/linux/include/linux/sched.h), so that a module can store additional
> security state data about each process. One approach would a
> standardized "pointer to data". Another approach -- though I don't
> know if it'd be too hard to do -- would be to support a startup-time
> parameter of the number of bytes to add to a process that can be used
> by security modules. Security modules would then need to request
> allocation from these storage areas ("please give me a block of 8 bytes
> in the task area") and they'd get the offset for their data.
> On-disk also needs to be handled, e.g., "Extended attributes".
>
> Yes, modules _CAN_ store state in themselves, but it'd be more painful
> to store them separately from the data structures they logically belong to.
I was thinking of just a void * field in each task_struct. Modules are then
responsible for hooking fork() to allocate and populate the state, and hooking
exit & friends to tear it down. This may not be the most efficient use of memory
when security state is large, but there are some security models that don't even
want to attach IDs to all processes, s having a fixed size of buffer per
task_struct isn't even always the right answer when security is in use.
> * What hooks should be included?
>
> ...
>
> However, I think inserting hooks for each system call is also important.
> It's likely that SOME module won't be well-supported by "existing" hooks,
> but adding hooks at the system call level gives enough room to cover the
> "surprise" cases.
Is there something wrong with just reloading the syscall table to achieve the same
effect?
> * More needs to be done about auditing.
> But I agree that would be outside of this group.
> Currently, it's not easy to do things like
> "don't allow this operation if I can't audit it" -- printk just
> doesn't cut it. It'd be nice to have something better than printk.
I'm a little confused here. I was thinking "if it can be mediated, it can be
audited", so auditiability should come for free with mediation and interposition.
When you say "don't allow this if I can't audit it", are you speaking from the
application process's perspective, or the module's perspective? The former seems
similar to the proposal to create a "may I?" system call, which has problems. The
latter seems like a gimmie under the current architecture. So I must not
understand what you're asking for.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Apr 18 2001 - 19:01:25 PDT