enforce()?

[BCS]

Hello Vladimir,

> On Mon, 21 Jun 2010 00:17:28 +0300, Walter Bright
> <newshound2 at digitalmars.com> wrote:
> 
>> An input to a dll is user input, and should be validated (for the
>> sake  of security, and other reasons). Validating it is not
>> debugging.
>> 
> I don't understand why you're saying this. Security checks in DLL
> functions are pointless, for the reasons I already outlined:
> 

import my.dll;

void fn()
{
    auto data = get.userUncheckedInput();
    my.dll.doSomething(data); // if doSomething dosn't check it's inputs, 
then this can cause a security flaw
}

Yes that's your dll's user's fault but adding the checks solves it even so. 
To boot, it reduces your support cost (as long as people read error message) 
and prevents the user from having to debug starting deep inside your dll.

>>> If it's for the sake of security - parameter validation in DLLs is
>>> pointless. If you are able to load and call code from inside a DLL,
>>> you  are already able to do everything that the DLL can. DLLs don't
>>> have any  "setuid"-like properties. If we were talking, for example,
>>> about  syscalls for a kernel module (functions called from userland
>>> but  executed in kernel land), then that would be a completely
>>> different  situation.
>>> 
>> If you, for example, provide a pluggable interface to your browser
>> app,  that's done using a dll, and you'd better validate anything you
>> get  through that plugin interface!
>> 
> Why? When your application loads a DLL, the DLL instantly gets access
> to  all of your application's memory, handles, and other resources.
> It's  running in the same address space and security context. You need
> to  completely trust the DLL - which is why new browsers (Google
> Chrome and  experimental Firefox versions) load plugins in separate
> processes with  reduced privileges.

And you can bet that every byte of data shipped back and forth via IPC is 
validated more than an air traveler at a TSA checkpoint.

As for the case where the dll is local, never attribute to malice that which 
can be adequately explained by stupidity. Unless you have source, you can't 
assume that the data coming out doesn't conation unvalidated user input and 
you should always assume that someone malicious will get ahold of that sooner 
or later.  
 
-- 
... <IXOYE><