Re: [Flightgear-devel] nasal iolib & security
"Curtis Olson" wrote: > We should strongly consider limiting writes to only a particular directory. Seconded and audit the Nasal interpreter code for leaks that might allow to escape this mentioned limitation _before_ even start allowing _any_ writes ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
Stuart Buchanan wrote: > Functionally, it seems reasonable to force all IO access through a > wrapper .nas file in $FG_ROOT/Nasal that could attempt to restrict > dangerous activities. This is actually possible, albeit obtuse. In the existing io.nas file (which currently adds the soft-coded readfile() function to the module) you can write a loop that inspects all the local variables for functions (you can get the local variable hash as caller(0)[0]), and replace each one with a wrapper version that checks the calling file (again using caller()) against a "blessed" list. Then the problem becomes one of maintaining the "blessing" rules such that they are secure. We can try to handle the issue from the other side too: identify all the spots where strings come in from outside the $FG_ROOT directory and audit these to make sure they can never be used as a script. One *really* easy way to do this would be to override the compile() function in globals.nas with a non-functional version. But compile() is really useful in practice... Another option, obviously, would be to just disable the io module again. But I enabled it this time because a new release is still well-off, and this seemed like a good time for experimentation. Andy - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
* Melchior FRANZ -- Friday 30 March 2007: > And if someone does a $ ln -s / ~/.fgfs/foo, why not?! Assuming that Nasal/IO can't make such links itself, of course. ;-) m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
* Gene Buckle -- Friday 30 March 2007: > Would it be reasonable to add a RESTRICT_IO define within Nasal itself > that stripped any path data from a filename and forced it to /tmp or some > other default directory specified by a non-nasal Nasal configuration file? Not sure what you mean with "Nasal itself". Nasal is in its own repository, and it's general purpose, so restriction by default is probably not very welcomed there. I rather thought of a settable validation callback function, that would be used by Nasal (if defined) with file name and operation type (read, write, append, ...). If the validation function returns 1 then Nasal goes ahead, otherwise it rejects. Such a function could then be defined in NasalSys.cxx and limit any file access as it pleases. Access to /tmp only is rather pointless. This directory is for short time storage, and shared memory on many systems. $FG_ROOT isn't really an option either, as it is (should be) read only. The user's "FG_HOME" (~/.fgfs/) is the only thing that makes sense to me, or even better: subdirectories of it, so that files on the top level are untouchable (autosave.xml, user preferences.xml etc.) This would still allow a lot of useful Nasal io. ~/.fgfs/Scenery/ could simply be added to FG_SCENERY, so one could add OBJECT entries to *.stg files there, etc. And if someone does a $ ln -s / ~/.fgfs/foo, why not?! m. PS: I haven't started this thread to make Andy aware of the problem. He *is* well aware of it, of course. He's the one who commented out the io-lib until now, and he mentioned the potential problems again on IRC yesterday. I just brought this to the list. :-) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
--- Melchior FRANZ wrote: > * Stuart Buchanan -- Friday 30 March 2007: > > Functionally, it seems reasonable to force all IO access through a > wrapper > > .nas file in $FG_ROOT/Nasal that could attempt to restrict dangerous > > activities. > > But every Nasal code would have to have access to use those > wrapper/validator functions ... and could then also overwrite them. > Or bypass the wrappers and use the wrapped core functions directly. > I assume any validation would have to be done in C++. I had forgotten that Nasal allows one to over-write a function in another namespace. Is is possible to declare a function/namespace "final"? I was going to suggest doing validation in the io.nas file. An alternative would be to simply add a sub-set of the IO functions to the system functions we already have in Scripting/NasalSys.*, with the validation done there. That would allow us to add I/O functions on an as-needed basis, though obviously restricts the innovative ideas we may have. Scenery editing is a use you already mentioned, and I guess data logging is another, but what other reasons do we have for generic I/O? -Stuart ___ Yahoo! Messenger - with free PC-PC calling and photo sharing. http://uk.messenger.yahoo.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
> * Stuart Buchanan -- Friday 30 March 2007: > > Functionally, it seems reasonable to force all IO access through a wrapper > > .nas file in $FG_ROOT/Nasal that could attempt to restrict dangerous > > activities. > > But every Nasal code would have to have access to use those > wrapper/validator functions ... and could then also overwrite them. > Or bypass the wrappers and use the wrapped core functions directly. > I assume any validation would have to be done in C++. > Would it be reasonable to add a RESTRICT_IO define within Nasal itself that stripped any path data from a filename and forced it to /tmp or some other default directory specified by a non-nasal Nasal configuration file? g. -- "I'm not crazy, I'm plausibly off-nominal!" Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
* Stuart Buchanan -- Friday 30 March 2007: > Functionally, it seems reasonable to force all IO access through a wrapper > .nas file in $FG_ROOT/Nasal that could attempt to restrict dangerous > activities. But every Nasal code would have to have access to use those wrapper/validator functions ... and could then also overwrite them. Or bypass the wrappers and use the wrapped core functions directly. I assume any validation would have to be done in C++. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal iolib & security
I don't know the right answer to any of this, but what I do know is that the internet is a much different place compared to a few years ago when we launched the FlightGear project. Originally the internet was much like a university, not without it's problems, but generally you could assume that everyone would be cooperative and at least trying to act in the best interest of humanity. Somewhere along the way, the internet became more like a marketplace. People acted mostly in their own best interest, but realized the larger structure needed to be strong in order for them to succeed individually. These days, the internet seems like it is becoming more like a war zone. We can't trust the people will act in the best interest of humanity or the best interest of FlightGear. We can't assume we are a little fish swimming under the radar screen. We have to expect that if we leave some gapping security hole open, someone will exploit it. Even if a proiblem isn't widely exploited, just having someone do something once, or even post a message on a security forum about our gapping security problems could be quite embarrassing. I know the MS has a long history of putting convenience and functionality above security, and that has let to a myriad of problems and exploits over the years. On the subject of file system permissions offering some protection ... there are different ways you can look at it. From a system admin perspective, protecting the system files is critical, who cares about user data. But from the user perspective, my files are *much* more valuable than the system. I can reload my system from DVD in a 1/2 a day and be back up and running. If I lose my data, I maybe totally screwed. If we do allow scripted writes, perhaps we should think about only giving this ability to "system" scripts that are loaded out of the Nasal directory. These presumably have been validated and reviewed by many people and would be safe ... unlike a nasal script attached to some aircraft you just downloaded from some random web site. We should strongly consider limiting writes to only a particular directory. I don't want to only depend on file system permissions for safety. If we do that, we should force everyone to create a fgfs user/group on their system, and run FG chroot'd in it's own directory. That's not going to happen though for most people so we can't depend on a secure sand box either. I wouldn't know how to even start setting up something like that on windows so I suspect most windows users wouldn't know either. If we do setup a series of protections and then enable script based IO, we should also think long and hard about making sure there aren't ways to circumvent our protections. And then we need to be vigilent and defend this code very carefully from this point on. And I agree that scripted IO isn't the only potential security issue in the FlightGear project, but this one has a lot of potential for abuse. Curt. On 3/30/07, Melchior FRANZ <[EMAIL PROTECTED]> wrote: Nasal (in SimGear) already had support for file I/O since the last Nasal update, but the line that would have activated it was commented out until yesterday. The now available Nasal "io" module allows some interesting stuff, such as direct appending of OBJECT entries to *.stg files from nasal code. But it's also potentially dangerous. What do we have to do to limit unwanted side effects, or rather: intentional malicious use of it? With Nasal io every aircraft from external sources can run Nasal code that reads local files and sends them over the net. Of course, every script, every Makefile, etc. can do that, too. But one wouldn't necessarily expect that from an fgfs aircraft. The operating system isn't really in any danger. It protects itself by means of file permissions/ACLs. Sending arbitrary stuff over the net could be done via voice interface. But here the host/port are set in $FG_ROOT/preferences.xml to localhost:1314, and the property is write protected. It's read before any nasal code runs, and later removing of the node's write protection and changing the values via Nasal doesn't have any effect. So, until now this should have been safe. But now Nasal code can change the values right in preferences.xml. Would we have to disallow writing to $FG_ROOT/preferences.xml? Other systems might be able to send arbitrary data, too, such as the MP/chat. Host/port are settable via command line, but also via properties, and that could be changed via aircraft *-set.xml file already (not tested). Sending data over net isn't the only problem. Some Nasal fun code could easily wipe the user's $HOME, or overwrite ~/.bashrc or other files that are executed automatically at login. What can, what shall we do with those? Of course, one could add a command line option that enables/disables the io lib, and make it off by default. But once it's on, it can enable itself, e.g. by writing to ~/.fgfsrc, or to fgrun's config, or any fgfs wrapper it
Re: [Flightgear-devel] nasal iolib & security
--- Melchior FRANZ wrote: > Nasal (in SimGear) already had support for file I/O since the > last Nasal update, but the line that would have activated it was > commented out until yesterday. The now available Nasal "io" > module allows some interesting stuff, such as direct appending > of OBJECT entries to *.stg files from nasal code. But it's also > potentially dangerous. What do we have to do to limit unwanted > side effects, or rather: intentional malicious use of it? Functionally, it seems reasonable to force all IO access through a wrapper .nas file in $FG_ROOT/Nasal that could attempt to restrict dangerous activities. That way - Aircraft would have access to "safe" I/O methods only - Any new IO function would have to be added to a single .nas file and could be easily scrutinized. - Installing a simple tarballed aircraft from outside CVS is less risky, as the aircraft .nas files has a limited number of IO functions available. Is this something that can sensibly be done within the parser? -Stuart ___ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] nasal iolib & security
Nasal (in SimGear) already had support for file I/O since the last Nasal update, but the line that would have activated it was commented out until yesterday. The now available Nasal "io" module allows some interesting stuff, such as direct appending of OBJECT entries to *.stg files from nasal code. But it's also potentially dangerous. What do we have to do to limit unwanted side effects, or rather: intentional malicious use of it? With Nasal io every aircraft from external sources can run Nasal code that reads local files and sends them over the net. Of course, every script, every Makefile, etc. can do that, too. But one wouldn't necessarily expect that from an fgfs aircraft. The operating system isn't really in any danger. It protects itself by means of file permissions/ACLs. Sending arbitrary stuff over the net could be done via voice interface. But here the host/port are set in $FG_ROOT/preferences.xml to localhost:1314, and the property is write protected. It's read before any nasal code runs, and later removing of the node's write protection and changing the values via Nasal doesn't have any effect. So, until now this should have been safe. But now Nasal code can change the values right in preferences.xml. Would we have to disallow writing to $FG_ROOT/preferences.xml? Other systems might be able to send arbitrary data, too, such as the MP/chat. Host/port are settable via command line, but also via properties, and that could be changed via aircraft *-set.xml file already (not tested). Sending data over net isn't the only problem. Some Nasal fun code could easily wipe the user's $HOME, or overwrite ~/.bashrc or other files that are executed automatically at login. What can, what shall we do with those? Of course, one could add a command line option that enables/disables the io lib, and make it off by default. But once it's on, it can enable itself, e.g. by writing to ~/.fgfsrc, or to fgrun's config, or any fgfs wrapper it finds in ~/bin/. :-) Should we do more, at all, than only auditing all Nasal contributions to CVS, and warning of aircraft or other fgfs data files with potential Nasal contents from outside & untrusted sources? I think we can overview the files in CVS by means of fg-check (or similar), and good old code review. Or should we limit all file access (read and write) to files under subdirectories of $FG_ROOT and/or ~/.fgfs/? People could still add links there to other directories. If so, how would we do that, without having to modify the files in simgear/nasal/, avoiding a Nasal fork, which would make updates from the Nasal repository harder. We'd need to make sure that all paths start with $FG_ROOT/*/ or $FG_HOME/*/ and contain no "..". I assume the nasal code would have to add a path validation callback method, or something!? m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
