headers
YAMAMOTO Takashi | 12 Nov 2007 01:55
Picon

Re: nfs optimization and veriexec

> YAMAMOTO Takashi wrote:
> 
> > yes, but i really don't want to have veriexec specific code in
> > each filesystems.  can't veriexec be modified to deal with it?
> 
> For a while I've been wanting to modify the way Veriexec does some
> things, namely the check of strict level in dev/verified_exec.c, by
> adding a kauth(9) scope for it to perform operations on.
> 
> 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?

> 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? :)
> 
> -e.

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?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elad Efrat | 12 Nov 2007 08:17
Picon

Re: nfs optimization and veriexec

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.
Permalink | Reply | 0 comments |
headers
Elad Efrat | 12 Nov 2007 10:13
Picon

Re: nfs optimization and veriexec

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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 12 Nov 2007 12:25
Picon

Re: nfs optimization and veriexec

> 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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elad Efrat | 12 Nov 2007 12:30
Picon

Re: nfs optimization and veriexec

YAMAMOTO Takashi wrote:

> i don't think the veriexec scope is a good idea in general
> or an acceptable solution for my specific case.

That's a different discussion... basically, Veriexec's pseudo
device provides services like loading, unloading, querying,
flushing, etc., and may support a few more in the future.

The idea is to be able to describe each action specifically
rather than a global "can control Veriexec" or "can't", at least
in the kauth(9) layer.

> can you explain why you want to make it veriexec specific?

Why I want to make what Veriexec specific? the scope? because
it collects actions relevant only for Veriexec.

-e.
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 12 Nov 2007 12:45
Picon

Re: nfs optimization and veriexec

> YAMAMOTO Takashi wrote:
> 
> > i don't think the veriexec scope is a good idea in general
> > or an acceptable solution for my specific case.
> 
> That's a different discussion... basically, Veriexec's pseudo
> device provides services like loading, unloading, querying,
> flushing, etc., and may support a few more in the future.
> 
> The idea is to be able to describe each action specifically
> rather than a global "can control Veriexec" or "can't", at least
> in the kauth(9) layer.
> 
> > can you explain why you want to make it veriexec specific?
> 
> Why I want to make what Veriexec specific? the scope? because
> it collects actions relevant only for Veriexec.
> 
> -e.

ah, ok.  then i can understand.
(i thought you meant veriexec-specific vfs/filesystem hooks
given that you suggested to make nfs call it.)

YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 12 Nov 2007 09:13
Picon

Re: nfs optimization and veriexec

> 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?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Elad Efrat | 12 Nov 2007 13:03
Picon

Re: nfs optimization and veriexec

YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>
>>> i don't think the veriexec scope is a good idea in general
>>> or an acceptable solution for my specific case.
>> That's a different discussion... basically, Veriexec's pseudo
>> device provides services like loading, unloading, querying,
>> flushing, etc., and may support a few more in the future.
>>
>> The idea is to be able to describe each action specifically
>> rather than a global "can control Veriexec" or "can't", at least
>> in the kauth(9) layer.
>>
>>> can you explain why you want to make it veriexec specific?
>> Why I want to make what Veriexec specific? the scope? because
>> it collects actions relevant only for Veriexec.
>>
>> -e.
> 
> ah, ok.  then i can understand.
> (i thought you meant veriexec-specific vfs/filesystem hooks
> given that you suggested to make nfs call it.)

What I mean, if to put it in more technical terms, is to have the
Veriexec scope with its veriexec_authorize() wrapper, and have
actions like KAUTH_VERIEXEC_LOAD, KAUTH_VERIEXEC_UNLOAD, etc.

If the NFS optimization conflicts only with Veriexec, and it makes sense
to do so, it's possible to add KAUTH_VERIEXEC_NFS_OPTIMIZE (or
whatever).
(Continue reading)

Permalink | Reply | 0 comments |
headers
YAMAMOTO Takashi | 13 Nov 2007 00:59
Picon

Re: nfs optimization and veriexec

> If the NFS optimization conflicts only with Veriexec, and it makes sense
> to do so, it's possible to add KAUTH_VERIEXEC_NFS_OPTIMIZE (or
> whatever).
> 
> What do you think?
> 
> -e.

it isn't so different from #ifdef VERIEXEC which is unacceptable for me.

for long term, i want to remove "lookup before create" from vfs.
so i hope to see the assumption is removed from veriexec, rather than
making the rest of kernel veriexec-aware.

YAMAMOTO Takashi
Permalink | Reply | 0 comments |
headers
Elad Efrat | 13 Nov 2007 08:21
Picon

Re: nfs optimization and veriexec

YAMAMOTO Takashi wrote:

> for long term, i want to remove "lookup before create" from vfs.
> so i hope to see the assumption is removed from veriexec, rather than
> making the rest of kernel veriexec-aware.

So it's not just an *NFS* optimization, is it? :)

Basically, Veriexec has a feature where it can prevent creation of new
files. I'd like to maintain that feature... or at least learn more about
what benefits this optimization has if the direction is that the two
can't co-exist.

Would it be possible to have Veriexec treat a "create unless exists" as
"create"? or would that break programs that open, say, log files with
O_RDWR|O_CREAT?

-e.
Permalink | Reply | 0 comments |

Gmane