Re: Allowing relative file imports
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!
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.
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
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.
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! :/
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?
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)
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/
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.
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!
Re: Allowing relative file imports
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
Re: Allowing relative file imports
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...
Re: Allowing relative file imports
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.
Re: Allowing relative file imports
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.
Re: Allowing relative file imports
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.
Re: Allowing relative file imports
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?
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. .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
Allowing relative file imports
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.
Re: Allowing relative file imports
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.
Re: Allowing relative file imports
On Wed, Mar 25, 2009 at 8:28 AM, Daniel Keep daniel.keep.li...@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!)
Re: Allowing relative file imports
Jarrett Billingsley wrote: On Wed, Mar 25, 2009 at 8:28 AM, Daniel Keep daniel.keep.li...@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
Re: Allowing relative file imports
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.
Re: Allowing relative file imports
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.
Re: Allowing relative file imports
On Wed, Mar 25, 2009 at 2:18 PM, Walter Bright newshou...@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.
Re: Allowing relative file imports
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
Re: Allowing relative file imports
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.
Re: Allowing relative file imports
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
