Subject: Re: nfs optimization and veriexec
To: YAMAMOTO Takashi <>
From: Elad Efrat <>
List: tech-security
Date: 11/12/2007 11:13:36
YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>>> Perhaps it's a good time to introduce said scope, and add an action
>>>> to indicate whether the NFS optimization can take place. Would that
>>>> work for you?
>>> i'm not sure what you mean by "an action to indicate whether the
>>> NFS optimization can take place."
>>> do you mean to make nfs call kauth_authorize_foo with the action?
>> Yes, but that call will only be made if Veriexec is compiled in.
>>>> The only thing I'm wondering about is what the kernel would do in
>>>> case Veriexec is not even compiled in... maybe just put in weak-aliased
>>>> stubs (similar to secmodel_start() in kern/init_main.c).
>>>> (perhaps having a file that is always compiled and contains weak-aliased
>>>> always-allow stubs for when conditionally compiled in scopes are not
>>>> compiled in is appropriate? :)
>>> i don't understand how it matters.
>>> do you mean a very veriexec specific scope which doesn't make sense at all
>>> unless veriexec is compiled in?
>> Yes.
>> -e.
> how is it different from #ifdef VERIEXEC?

For your specific case, it's not that different, other than the fact
it provides the ability to, in the future, control just that very
optimization. (correct me if I'm wrong -- and it's likely that I am,
given my lack of experience with NFS -- but can the optimization
be worded as "bypass normal file creation procedure"?)

The Veriexec scope I'm talking about is in my plans for quite a while,
and has nothing to do with the NFS optimization -- the latter was just
the trigger for me to bring it up and discuss whether it may be
appropriate to introduce it, and at the same time, provide a solution
to the NFS optimization.

In any case, I don't object putting an #ifdef, but figured I'd share
other ideas I have. :)