View mode: basic / threaded / horizontal-split · Log in · Help
March 27, 2009
Re: Allowing relative file imports
Georg Wrede wrote:
> Walter Bright wrote:
>> grauzone wrote:
>>> Walter Bright wrote:
>>>> http://www.comeaucomputing.com lets you upload random C++ code, 
>>>> compile it on their system, and view the messages put out by their 
>>>> compiler. Suppose you did it with D, had it import some sensitive 
>>>> file, and put it out with a pragma msg statement?
>>>
>>> Your compiler can do the same:
>>> http://codepad.org/hWC9hbPQ
>>
>> That's awesome!
> 
> And the system seems protected, too: http://codepad.org/mzAgmvZZ

And I'll raise you: http://codepad.org/bp5nsprd
March 27, 2009
Re: Allowing relative file imports
Georg Wrede wrote:
> Walter Bright wrote:
>> There's no reason in principle that D could not be used instead.
> 
> True. But then, what would happen to the Systems Language image of D in 
> folks' minds, if it is run in a browser, next to Javascript, Java, and 
> who knows what "toy" languages? Would Phobos then have to be replaced 
> with another library for running the app within a browser?

One would use the "safe" subset of D for that.

>> This means that we should think about security issues. Compiling 
>> untrusted code should not result in an attack on your system.
> 
> Well, removing disk file ops, and OS APIs in general would be the first 
> step. And if you restrict some include paths, then, for symmetry, you 
> should restrict all command line file paths similarly. I think there's a 
> lot to do here. A half baked version would just give bad PR, but a 
> proper and tight version presumably is quite some work -- but is the 
> reward worth it? Is it established that enough people would use it?
> 
> Are you thinking of having a parallell Phobos tree for this, or doing it 
> with conditional compilation?

I haven't thought that far.


> But really, what I'm wondering here is, is this yet another "hey let's 
> do this" thing?? Can we go on like this till September? And where would 
> we be then? Shouldn't there be like a roadmap, or something? Or priorities?

The import file thing has been around a long time. I am not planning on 
changing it in the near future.
March 27, 2009
Re: Allowing relative file imports
Walter Bright wrote:
> Georg Wrede wrote:
>> Walter Bright wrote:
>>> grauzone wrote:
>>>> Walter Bright wrote:
>>>>> http://www.comeaucomputing.com lets you upload random C++ code, 
>>>>> compile it on their system, and view the messages put out by their 
>>>>> compiler. Suppose you did it with D, had it import some sensitive 
>>>>> file, and put it out with a pragma msg statement?
>>>>
>>>> Your compiler can do the same:
>>>> http://codepad.org/hWC9hbPQ
>>>
>>> That's awesome!
>>
>> And the system seems protected, too: http://codepad.org/mzAgmvZZ
> 
> And I'll raise you: http://codepad.org/bp5nsprd

Not that I'm discussing against the import -J switch, but the compiler 
is also running inside a sandbox. At least it looks like:

http://codepad.org/ZGON3u56

(my interpretation: compiler crashes inside the sandbox)

Conclusion: the compiler doesn't need to be safe. Actually, using a 
sandbox approach is probably more secure than trying to fix all compiler 
security issues.
March 27, 2009
Re: Allowing relative file imports
Walter Bright wrote:
> Georg Wrede wrote:
>> Walter Bright wrote:
>>> grauzone wrote:
>>>> Walter Bright wrote:
>>>>> http://www.comeaucomputing.com lets you upload random C++ code, 
>>>>> compile it on their system, and view the messages put out by their 
>>>>> compiler. Suppose you did it with D, had it import some sensitive 
>>>>> file, and put it out with a pragma msg statement?
>>>>
>>>> Your compiler can do the same:
>>>> http://codepad.org/hWC9hbPQ
>>>
>>> That's awesome!
>>
>> And the system seems protected, too: http://codepad.org/mzAgmvZZ
> 
> And I'll raise you: http://codepad.org/bp5nsprd

Unfair! You must have a newer Phobos than I! :/
March 27, 2009
Re: Allowing relative file imports
Walter Bright wrote:
> Georg Wrede wrote:
>> I mean, how often do you see web sites where stuff is fed to a C 
>> compiler and the resulting programs run????? (Yes it's too slow, but 
>> that's hardly the point here.) That is simply not done.
> 
> Consider the Java JVM. You've probably got one installed on your 
> computer. It gets java code from gawd knows where (as the result of web 
> browsing), it compiles it, and runs it on your machine unbeknownst to you.


The thing about the JVM, though, is that it runs in a sandbox. Try to 
access the file system, or to change the display mode, from an applet or 
WebStart-enabled app. It's not going to happen without the user granting 
permission. And you know every time the JVM starts up, either from the 
Sun logo displayed as the applet loads, the Java logo in the system 
tray, or the WebStart dialog that asks permission to run the applet.

Java developers wanting to use the platform for games actually complain 
that there's too much security (or, more accurately, that the security 
dialogs are either too scary for the average user or ignored 
completely). What's worse are the independently developed browser 
plugins that allow untrusted executable binaries to run.

> 
> .NET does that too.
> 
> Every day my browser downloads javascript code, compiles it, and runs it.
> 
> There's no reason in principle that D could not be used instead.
> 
> This means that we should think about security issues. Compiling 
> untrusted code should not result in an attack on your system.
> 
> http://www.comeaucomputing.com lets you upload random C++ code, compile 
> it on their system, and view the messages put out by their compiler. 
> Suppose you did it with D, had it import some sensitive file, and put it 
> out with a pragma msg statement?
March 27, 2009
Re: Allowing relative file imports
grauzone wrote:
> Walter Bright wrote:
>> Georg Wrede wrote:
>>> Walter Bright wrote:
>>>> grauzone wrote:
>>>>> Walter Bright wrote:
>>>>>> http://www.comeaucomputing.com lets you upload random C++ code, 
>>>>>> compile it on their system, and view the messages put out by their 
>>>>>> compiler. Suppose you did it with D, had it import some sensitive 
>>>>>> file, and put it out with a pragma msg statement?
>>>>>
>>>>> Your compiler can do the same:
>>>>> http://codepad.org/hWC9hbPQ
>>>>
>>>> That's awesome!
>>>
>>> And the system seems protected, too: http://codepad.org/mzAgmvZZ
>>
>> And I'll raise you: http://codepad.org/bp5nsprd
> 
> Not that I'm discussing against the import -J switch, but the compiler 
> is also running inside a sandbox. At least it looks like:
> 
> http://codepad.org/ZGON3u56
> 
> (my interpretation: compiler crashes inside the sandbox)
> 
> Conclusion: the compiler doesn't need to be safe. Actually, using a 
> sandbox approach is probably more secure than trying to fix all compiler 
> security issues.

What's really so hard about:

-J`pwd`/whatever

(at least on *nix)
March 27, 2009
Re: Allowing relative file imports
Jarrett Billingsley wrote:
> One, you do not use Javascript as a server-side scripting language.

Why not? Server-side JavaScript exists since 1996.

http://www.aptana.com/jaxer/
http://www.modjs.org/
March 27, 2009
Re: Allowing relative file imports
grauzone wrote:
> Conclusion: the compiler doesn't need to be safe. Actually, using a 
> sandbox approach is probably more secure than trying to fix all compiler 
> security issues.

I've been reading a bunch of articles on making secure software lately. 
The consensus is that relying on one aspect to make software secure 
leaves one vulnerable. The more reliable way is to have layered security 
- so that if an attacker gets past one layer, he's got another layer he 
must get past.

Compiler security issues should be addressed, *and* the compiler should 
be run in a sandbox.

I'm also thinking of adjusting the code generation to reduce the ability 
to take advantage of buffer overflows, even though you shouldn't have 
buffer overflows in D.
March 27, 2009
Re: Allowing relative file imports
Mike Parker wrote:
> The thing about the JVM, though, is that it runs in a sandbox. Try to 
> access the file system, or to change the display mode, from an applet or 
> WebStart-enabled app. It's not going to happen without the user granting 
> permission. And you know every time the JVM starts up, either from the 
> Sun logo displayed as the applet loads, the Java logo in the system 
> tray, or the WebStart dialog that asks permission to run the applet.

You can run native executables in a sandbox, too. The hardware even 
supports that!
March 27, 2009
Re: Allowing relative file imports
On Fri, Mar 27, 2009 at 2:14 PM, Walter Bright
<newshound1@digitalmars.com> wrote:
>
> I'm also thinking of adjusting the code generation to reduce the ability to
> take advantage of buffer overflows, even though you shouldn't have buffer
> overflows in D.

At least not in debug mode.  ;)
1 2 3 4
Top | Discussion index | About this forum | D home