www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allowing relative file imports

reply Daniel Keep <daniel.keep.lists gmail.com> writes:
There seem to have been a few tickets thus far from people wanting to do
relative file imports using the -J switch.  Walter has stated that this
is explicitly disallowed as a defensive measure, which is fine.

I was going to post the following as an enhancement request, but I
thought it might be better if it was discussed first.

TLDR: relative paths should be safe if we disallow symlinks, disallow -J
to be used except for a small whitelist and require a specially-named
file to be present in any imported directory.

Disclaimer: I'm not a security guru.

  -- Daniel

There have been at least two reports thus far (2103 and 2759) of people
attempting to use relative imports with the -J compile-time file import
feature.

It has been stated that this is explicitly disabled due to security
concerns.

I suggest that adding relative paths (provided paths cannot escape the
base directory) is not less secure; it should already be possible to
read an arbitrary file using the feature.

Let us assume relative paths are allowed, and that the path is
"collapsed" to remove all parent (..) references, and clipped to the
base directory.  The only way to "escape" this directory is for one of
three things to happen:

1. there is a symlink to a parent directory in the import path,
2. there is a device of interest mounted in the import path or
3. the user was tricked into specifying a higher directory in the first
place.

Clearly, #3 is already a problem: one could always specify -J/etc in a
Makefile to read any system configuration file that the user has access
to.  #2 is only a problem if the compiling user is an administrator and
tremendously stupid, which is not so much an issue with DMD but with the
user.  #1 is something which could also be done in a Makefile.

It should be noted that this is really no different to executing
arbitrary code on a machine.  That said, compiling a program is not
typically thought of as "executing" code, so some restrictions in this
case would probably be prudent.

Therefore, I believe the following should be sufficient to ensure
relative paths are safe to include:

1. Ensure that symlinks are NOT followed.  This also applies under
Windows for junctions and symlinks (I believe it should be enough to use
GetFileAttributesEx on each path component and reject it if it has the
FILE_ATTRIBUTE_REPARSE_POINT attribute, although I cannot verify this
with XP; see
http://blogs.msdn.com/oldnewthing/archive/2004/12/27/332704.aspx).

2. Disallow -J to be the root of any drive or filesystem, and only allow
-J to be used from the following roots: %USERPROFILE% for Windows and ~
for *nix.  Possibly, this should be configured or overridable in sc.ini;
an extendible whitelist would be good.

3. Require that any directory you attempt to read from using file
imports MUST have either a "_import" or ".import" file (or whatever name
seems appropriate) present in it.

The first should prevent symlinks from being a potential attack vector,
the second should prevent most casual malicious behaviour, and the third
will ensure that the user not only have read access but WRITE access as
well (or whoever owns the directory explicitly allowed for D file imports.)

This should hopefully be sufficient to allow for relative imports.
Mar 25 2009
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Daniel Keep schrieb:
 There have been at least two reports thus far (2103 and 2759) of people
 attempting to use relative imports with the -J compile-time file import
 feature.

Please note also my posting "Proposal for fixing import("file")" on 14th March in this NG.
Mar 25 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Frank Benoit wrote:
 Daniel Keep schrieb:
 There have been at least two reports thus far (2103 and 2759) of people
 attempting to use relative imports with the -J compile-time file import
 feature.

Please note also my posting "Proposal for fixing import("file")" on 14th March in this NG.

Should go into bugzilla with a link to that thread.
Mar 25 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Mar 25, 2009 at 8:28 AM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:

 2. Disallow -J to be the root of any drive or filesystem, and only allow
 -J to be used from the following roots: %USERPROFILE% for Windows and ~
 for *nix. =A0Possibly, this should be configured or overridable in sc.ini=

 an extendible whitelist would be good.

%USERPROFILE% is probably a bad choice on Windows pre-Vista, mostly because OPTLINK will die with paths with spaces in them (go OPTLINK). That and, I have never used my %USERPROFILE% directory for anything :P (probably because it's such a long god-damned path!)
Mar 25 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Jarrett Billingsley wrote:
 On Wed, Mar 25, 2009 at 8:28 AM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:
 
 2. Disallow -J to be the root of any drive or filesystem, and only allow
 -J to be used from the following roots: %USERPROFILE% for Windows and ~
 for *nix.  Possibly, this should be configured or overridable in sc.ini;
 an extendible whitelist would be good.

%USERPROFILE% is probably a bad choice on Windows pre-Vista, mostly because OPTLINK will die with paths with spaces in them (go OPTLINK). That and, I have never used my %USERPROFILE% directory for anything :P (probably because it's such a long god-damned path!)

True, but what else is there? That's where "My Documents" lives; there's no other "safe" directory I could think of for Windows. If the error message including the language "You may need to add this directory, or a parent of it, to the whitelist in %PATHTODMD%\sc.ini" it should be OK. The point here is to allow it safely. -- Daniel
Mar 25 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 It should be noted that this is really no different to executing
 arbitrary code on a machine.  That said, compiling a program is not
 typically thought of as "executing" code, so some restrictions in this
 case would probably be prudent.

Here's the scenario I'm concerned about. Let's say you set up a website that instead of supporting javascript, supports D used as a scripting language. The site thus must run the D compiler on the source code. When it executes the resulting code, that execution presumably will run in a "sandbox" at a low privilege level. But the compiler itself will be part of the server software, and may run at a higher privilege. The import feature could possible read any file in the system, inserting it into the executable being built. The running executable could then supply this information to the attacker, even though it is sandboxed. This is why even using the import file feature must be explicitly enabled by a compiler switch, and which directories it can read must also be explicitly set with a compiler switch. Presumably, it's a lot easier for the server software to control the compiler switches than to parse the D code looking for obfuscated file imports.
Mar 25 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Mar 25, 2009 at 2:18 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Here's the scenario I'm concerned about. Let's say you set up a website that
 instead of supporting javascript, supports D used as a scripting language.
 The site thus must run the D compiler on the source code. When it executes
 the resulting code, that execution presumably will run in a "sandbox" at a
 low privilege level.

 But the compiler itself will be part of the server software, and may run at
 a higher privilege. The import feature could possible read any file in the
 system, inserting it into the executable being built. The running executable
 could then supply this information to the attacker, even though it is
 sandboxed.

 This is why even using the import file feature must be explicitly enabled by
 a compiler switch, and which directories it can read must also be explicitly
 set with a compiler switch. Presumably, it's a lot easier for the server
 software to control the compiler switches than to parse the D code looking
 for obfuscated file imports.

One, you do not use Javascript as a server-side scripting language. That task is usually relegated to (shiver) PHP, Ruby, Python, Java or the like. Javascript, as far as I know, only has a place in web programming in client-side (browser-side) scripting. The only thing you can do from the client is maybe munge some POST data, and then that's a logic error on the part of your server script, not anything to do with the language. Two, if you did replace your server-side scripting language with something like D, there are no more or fewer security holes than with any other server-side scripting language. The entire point of server-side scripts is that they are invisible to the clients, and the clients never see, modify, or upload server-side scripts of their own. It's not possible to put a malicious file import in the D server page unless you actually have access to the server, and if an attacker does have that kind of access, D is no more or less secure than any other server-side language. They'd all be vulnerable. The attacker could just change the server's compiler flags to change the import directory anyway. I understand your desire to restrict the use of import expressions, but your example just does not add up.
Mar 25 2009
parent Miles <_______ _______.____> writes:
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/
Mar 27 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 It should be noted that this is really no different to executing
 arbitrary code on a machine.  That said, compiling a program is not
 typically thought of as "executing" code, so some restrictions in this
 case would probably be prudent.

Here's the scenario I'm concerned about. Let's say you set up a website that instead of supporting javascript, supports D used as a scripting language. The site thus must run the D compiler on the source code. When it executes the resulting code, that execution presumably will run in a "sandbox" at a low privilege level. But the compiler itself will be part of the server software, and may run at a higher privilege.

If you're thinking of something like ASP.NET for D, whereby the server executes a D compiler, then I think this would be a serious design flaw of the software; the D compiler itself should be executing with the absolute minimum permissions necessary to function, and preferably in a VM or a jail.
 The import feature could possible read any file
 in the system, inserting it into the executable being built. The running
 executable could then supply this information to the attacker, even
 though it is sandboxed.
 
 This is why even using the import file feature must be explicitly
 enabled by a compiler switch, and which directories it can read must
 also be explicitly set with a compiler switch. Presumably, it's a lot
 easier for the server software to control the compiler switches than to
 parse the D code looking for obfuscated file imports.

Well, my proposal should -improve- security because currently it's possible to read any file the compiler has access to simply by compiling via a Makefile or any other build process. If the code cannot set command-line switches, then there's no difference, so let's ignore that case. Let's assume the code CAN set switches. There's nothing to stop it doing this:
 dmd -J/etc evil.d && evil

 module evil;
 const PASSWD = cast(char[]) import("passwd");
 import std.stdio;
 void main()
 {
     writefln("200 OK\nContent-Type: text/plain\n");
     writef("%s", PASSWD);
 }

Hence why I proposed a whitelist in sc.ini itself. This way, you can't trick the compiler (either by controlling the command-line or by tricking the user) into giving you the sensitive file directly. By disallowing symlinks, you also remove the ability to "escape" a directory tree. Finally, the requirement for a ".dimport" or "_dimport" file or something ensures that folders have to explicitly cleared for file imports. Combined with the whitelist and removal of symlinks, it should be more or less impossible to get access to a file you shouldn't. Perhaps it might be worthwhile to do a mock compiler (that just attempts to read a provided filename using a -J switch) with these semantics and see if it's possible to exploit it in any way... -- Daniel
Mar 25 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 If the code cannot set command-line switches, then there's no
 difference, so let's ignore that case.  Let's assume the code CAN set
 switches.  There's nothing to stop it doing this:

It's a lot easier to scrub command line switches than to try to scrub D source code. It's the server that runs dmd, not the client. The rest of your proposal may be tight, I don't really know. I do wish to keep it, however, as simple as possible and the current scheme does that.
Mar 25 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 If the code cannot set command-line switches, then there's no
 difference, so let's ignore that case.  Let's assume the code CAN set
 switches.  There's nothing to stop it doing this:

It's a lot easier to scrub command line switches than to try to scrub D source code. It's the server that runs dmd, not the client. The rest of your proposal may be tight, I don't really know. I do wish to keep it, however, as simple as possible and the current scheme does that.

Sorry, poor choice of words. I should have said "Let's assume a malicious party who either provided the code or knows how to exploit the code can set switches." I'm not proposing scrubbing the source in any way. -- Daniel
Mar 25 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 It should be noted that this is really no different to executing
 arbitrary code on a machine.  That said, compiling a program is not
 typically thought of as "executing" code, so some restrictions in this
 case would probably be prudent.

Here's the scenario I'm concerned about. Let's say you set up a website that instead of supporting javascript, supports D used as a scripting language. The site thus must run the D compiler on the source code. When it executes the resulting code, that execution presumably will run in a "sandbox" at a low privilege level. But the compiler itself will be part of the server software, and may run at a higher privilege. The import feature could possible read any file in the system, inserting it into the executable being built. The running executable could then supply this information to the attacker, even though it is sandboxed. This is why even using the import file feature must be explicitly enabled by a compiler switch, and which directories it can read must also be explicitly set with a compiler switch. Presumably, it's a lot easier for the server software to control the compiler switches than to parse the D code looking for obfuscated file imports.

As almost everybody else here, I've maintained a couple of websites. Using D to write CGI programs (that are compiled, real binaries) is appealing, but I'd never even think about having the web server itself use the D compiler!!! 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. Rdmd might get one thinking of such, but then, how many websites use dynamically created PHP? Dynamically created pages yes, but with static PHP source. I must be missing something big here...
Mar 26 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 Daniel Keep wrote:
 It should be noted that this is really no different to executing
 arbitrary code on a machine.  That said, compiling a program is not
 typically thought of as "executing" code, so some restrictions in this
 case would probably be prudent.

Here's the scenario I'm concerned about. Let's say you set up a website that instead of supporting javascript, supports D used as a scripting language. The site thus must run the D compiler on the source code. When it executes the resulting code, that execution presumably will run in a "sandbox" at a low privilege level. But the compiler itself will be part of the server software, and may run at a higher privilege. The import feature could possible read any file in the system, inserting it into the executable being built. The running executable could then supply this information to the attacker, even though it is sandboxed. This is why even using the import file feature must be explicitly enabled by a compiler switch, and which directories it can read must also be explicitly set with a compiler switch. Presumably, it's a lot easier for the server software to control the compiler switches than to parse the D code looking for obfuscated file imports.

As almost everybody else here, I've maintained a couple of websites. Using D to write CGI programs (that are compiled, real binaries) is appealing, but I'd never even think about having the web server itself use the D compiler!!! 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.

Of course it is, probably just not in C. Last time I looked, there are two concepts around, one of "statically-generated dynamic pages" and one of "entirely dynamic pages". I know because I installed an Apache server and at that time support for statically-generated dynamic pages was new. What that means is this: a) statically-generated dynamic = you generate the page once, it's good until the source of the page changes; b) "really" dynamic page = you generate the page at each request.
 Rdmd might get one thinking of such, but then, how many websites use 
 dynamically created PHP? Dynamically created pages yes, but with static 
 PHP source.
 
 I must be missing something big here...

I think D with rdmd would be great for (a). Andrei
Mar 26 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:
 Georg Wrede wrote:
 Walter Bright wrote:
 Daniel Keep wrote:
 It should be noted that this is really no different to executing
 arbitrary code on a machine.  That said, compiling a program is not
 typically thought of as "executing" code, so some restrictions in this
 case would probably be prudent.

Here's the scenario I'm concerned about. Let's say you set up a website that instead of supporting javascript, supports D used as a scripting language. The site thus must run the D compiler on the source code. When it executes the resulting code, that execution presumably will run in a "sandbox" at a low privilege level. But the compiler itself will be part of the server software, and may run at a higher privilege. The import feature could possible read any file in the system, inserting it into the executable being built. The running executable could then supply this information to the attacker, even though it is sandboxed. This is why even using the import file feature must be explicitly enabled by a compiler switch, and which directories it can read must also be explicitly set with a compiler switch. Presumably, it's a lot easier for the server software to control the compiler switches than to parse the D code looking for obfuscated file imports.

As almost everybody else here, I've maintained a couple of websites. Using D to write CGI programs (that are compiled, real binaries) is appealing, but I'd never even think about having the web server itself use the D compiler!!! 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.

Of course it is, probably just not in C. Last time I looked, there are two concepts around, one of "statically-generated dynamic pages" and one of "entirely dynamic pages". I know because I installed an Apache server and at that time support for statically-generated dynamic pages was new. What that means is this: a) statically-generated dynamic = you generate the page once, it's good until the source of the page changes; b) "really" dynamic page = you generate the page at each request.

Have you ever done web development? If so, did you actually do *code generation* on each page request? If so, I never want to work with you. Web applications in compiled languages pretty much never invoke the compiler when they're running. Very few programs need a compiler on the machine they're deployed to. It's a security risk, and it's an unneeded dependency, and it pretty much guarantees a maintenance and debugging problem, and it promises performance issues.
Mar 26 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:
 Georg Wrede wrote:
 Walter Bright wrote:
 Daniel Keep wrote:
 It should be noted that this is really no different to executing
 arbitrary code on a machine.  That said, compiling a program is not
 typically thought of as "executing" code, so some restrictions in this
 case would probably be prudent.

Here's the scenario I'm concerned about. Let's say you set up a website that instead of supporting javascript, supports D used as a scripting language. The site thus must run the D compiler on the source code. When it executes the resulting code, that execution presumably will run in a "sandbox" at a low privilege level. But the compiler itself will be part of the server software, and may run at a higher privilege. The import feature could possible read any file in the system, inserting it into the executable being built. The running executable could then supply this information to the attacker, even though it is sandboxed. This is why even using the import file feature must be explicitly enabled by a compiler switch, and which directories it can read must also be explicitly set with a compiler switch. Presumably, it's a lot easier for the server software to control the compiler switches than to parse the D code looking for obfuscated file imports.

As almost everybody else here, I've maintained a couple of websites. Using D to write CGI programs (that are compiled, real binaries) is appealing, but I'd never even think about having the web server itself use the D compiler!!! 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.

Of course it is, probably just not in C. Last time I looked, there are two concepts around, one of "statically-generated dynamic pages" and one of "entirely dynamic pages". I know because I installed an Apache server and at that time support for statically-generated dynamic pages was new. What that means is this: a) statically-generated dynamic = you generate the page once, it's good until the source of the page changes; b) "really" dynamic page = you generate the page at each request.
 Rdmd might get one thinking of such, but then, how many websites use 
 dynamically created PHP? Dynamically created pages yes, but with 
 static PHP source.

 I must be missing something big here...

I think D with rdmd would be great for (a).

I'm still not sure what you mean. I see it as static (as in plain html) vs dynamic (as, FaceBook, Wikipedia, etc.). Now these dynamic pages can be php pages, that get their data from a database (I guess wikimedia would be a good example), but neither case involves creating the server side programs (as in *.php, *.cgi) dynamically. Or sort-of. Many PHP web applications contain pages that dynamically choose which sub-elements (say a news ticker) to "show", but that's still just combinations of prewritten "mini-pages", if you will. (Some even have them in a RDBMS.) But a use case where one would need to create CGI-BIN stuff that is so variable as to warrant recompiling, I don't see. One would rather have a set of small D programs (binaries) that do small things, like one for latest news, one for informing about others online, etc. -------- Of course there are sites where I can type D source code in a box, and have it compiled and run. But I'm sure neither of us are talking about such sites? I mean, to do that, the administrator usually knows what he's doing! And can take care of himself, which means we don't have to accommodate his needs.
Mar 26 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:
 As almost everybody else here, I've maintained a couple of websites.
 
 Using D to write CGI programs (that are compiled, real binaries) is 
 appealing, but I'd never even think about having the web server itself 
 use the D compiler!!!
 
 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.

Similarly, how often do you do code generation in a PHP application? You can do it, and I'm sure people use eval for small things, but anything bigger than that, it just becomes a mess.
Mar 26 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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. .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?
Mar 26 2009
next sibling parent reply grauzone <none example.net> writes:
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. .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?

Your compiler can do the same: http://codepad.org/hWC9hbPQ
Mar 26 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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!
Mar 26 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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
Mar 27 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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
Mar 27 2009
next sibling parent reply grauzone <none example.net> writes:
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.
Mar 27 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
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)
Mar 27 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 27 2009
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 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.


Correction: at least not in non-release mode. That "release" flag really has to be renamed.
Mar 27 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
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! :/
Mar 27 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
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.

I was talking server side. But now that you mention, it would be kind of cool to have D within the browser.
 .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.

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?
 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?
 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?

Well, even they don't let you run the compiled programs. (But that's probably mostly because kids would waste all the cpu cycles.) And I'd bet the compiler is chrooted, just to be safe. Chrooting would take care of that D pragma "exploit", too. Ahhh, about links: it's the responsibility of the operator to see that there are no unnecessary links within the chroot tree. But some installations need (and others want, for specific reasons) to have soft links, so I don't think the compiler should frawn upon them. It's really not the compiler's responsibility. Similarly, there may be hard links, and while even they can be "detected", it's really not called for. (One could call this Compartmentalization of Responsibility, unheard of in Windows.) --- 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?
Mar 27 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 27 2009
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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?

Mar 27 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
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!
Mar 27 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
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. ;)
Mar 27 2009