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

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.

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.

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! :/

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?

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)

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/

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.

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!

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.  ;)