On Fri, 13 Sep 2013 23:01:05 +0100, Rebecca wrote in message
52338b21.9010...@bham.ac.uk:
From: James Turner zakalawe@ma... - 2013-09-13 06:13:59
On 11 Sep 2013, at 10:16, Markus Wanner markus@... wrote:
far more useful would be to get ARM working
This patch should do that, while changing
On 09/14/2013 12:07 PM, James Turner wrote:
Thanks, I'll apply these as-is to the 2.12 branch. For master/next, I
think a slight re-factoring can make things cleaner. (E.g a
simgear::strutils::sanitize_printf_format)
Nice, thanks.
What is the recommended notification channel from Debian to
From: James Turner zakalawe@ma... - 2013-09-13 06:13:59
On 11 Sep 2013, at 10:16, Markus Wanner markus@... wrote:
I think some of the more recent patches didn't flow upstream, yet. I'm
focusing on getting it working properly on Debian, first. And getting
2.12 in. Just a matter of time. Sorry
http://gigaom.com/apple/mac-botnet-how-to-ensure-you-are-not-part-of-the-problem/
http://www.zdnet.com/blog/security/safarimacbook-first-to-fall-at-pwn2own-2011/8358
I only hope someone is revising submitted code...--
I've now closed two more security holes:
1. By setting an evil browser-app property and opening the browser
help aircraft from questionable sources could execute arbitrary
code in the calling shell under Unix:
setprop(/sim/startup/browser-app, rm -rf ~ getprop(/sim/fg-home));
You could however limit every io.open to only have write access to a
single directory as stated before, not allowing more sources...?
Then you could skip the .xml extention checks? As this would disable any
modification outside the predefined directory. It could be set to
something like
I've locked the system further down. If people desire, then we
can disable any file access by default. At the moment writing
should only be possible with pattern ~/.fgfs/Export/* and
~/.fgfs/Scenery/*.stg.
m.
-
Check out the
* Melchior FRANZ -- Monday 16 June 2008:
I've locked the system further down.
var read_rules = [
[root ~ /*, 1],
[home ~ /*, 1],
];
var write_rules = [
[home ~ /Scenery/*.stg, 1],
[home ~ /Export/*, 1],
];
The 1 means ALLOW, whereas 0 would mean
The rules are now read from $FG_ROOT/Nasal/IOrules or, if
available, $FG_HOME/Nasal/IOrules. That way people who don't
have write permission for $FG_HOME/Nasal/io.nas can still
extend and modify the rules. The default is:
READ ALLOW $FG_ROOT/*
READ ALLOW $FG_HOME/*
WRITE ALLOW
Ehlo ppl ;)
Can't you just restrict the io to the $FG_HOME dir or something? And if
the user (I doubt that John Doe needs this...) requires permissions some
where else then he/she could tell fgfs that with a cmd line argument?
like --io-read=/myDir --io-read=/tmp --io-write=/etc/passwd ?
* Sven Almgren -- Monday 16 June 2008:
Can't you just restrict the io to the $FG_HOME dir or something?
Sure:
READ ALLOW $FG_HOME/*
WRITE ALLOW $FG_HOME/*
like --io-read=/myDir --io-read=/tmp --io-write=/etc/passwd ?
Any of the options overwrites a previous one with the same name,
so
* Melchior FRANZ -- Monday 16 June 2008:
At least for now we should be reasonably safe from evil people
and have time to find better solutions.
BTW: Why the sudden paranoia? Not that we should have waited
much longer for some security enhancements in any case, but the
fact that there seem now
Melchior FRANZ wrote:
* Melchior FRANZ -- Monday 16 June 2008:
At least for now we should be reasonably safe from evil people
and have time to find better solutions.
BTW: Why the sudden paranoia? Not that we should have waited
much longer for some security enhancements in any case,
On Mon, 16 Jun 2008 15:40:54 +0200, Sven wrote in message
[EMAIL PROTECTED]:
Melchior FRANZ wrote:
* Melchior FRANZ -- Monday 16 June 2008:
At least for now we should be reasonably safe from evil people
and have time to find better solutions.
BTW: Why the sudden paranoia?
Melchior FRANZ wrote:
It's well known that Nasal has an io module with wrappers around
fopen(), fclose(), etc. An aircraft that you install, or even
scenery objects with embedded Nasal could in the past use this
to delete the contents of your whole home directory, or to append
commands to
Melchior FRANZ wrote:
* Sven Almgren -- Monday 16 June 2008:
like --io-read=/myDir --io-read=/tmp --io-write=/etc/passwd ?
One could, of course, use this instead:
--prop:io-read=/myDir --prop:io-read[1]=/tmp ...
I don't consider any command line option a security thread since writing
to
It's funny that nobody cared a year long, and now that the danger
is supposed to be banned, people get scared and nervous. :-}
* Erik Hofman -- Monday 16 June 2008:
(What are the reasons to write to a file anyway?)
Writing non-PropertyList XML files, like they are used in the
traffic manager
Sven Almgren wrote:
But is this really needed? How does M$ flightsim extensions do? You
have to trust the source somewhat, We could sneak in bad code in
fgfs too, and ppl would run it anyway... Can the addoncreators be
trustet as much as we can?
Sure. FlightGear is a local program, and
* Melchior FRANZ -- Monday 16 June 2008:
Writing non-PropertyList XML files, like they are used in the
traffic manager and for flight plans.
Correction: not for flight plans -- these are PropertyLists. But
for the other stuff like parking files etc.
The power of a system isn't defined by what
Melchior FRANZ wrote:
It's funny that nobody cared a year long, and now that the danger
is supposed to be banned, people get scared and nervous. :-}
I don't, I just though I could help here.
Erik
-
Check out the new
Melchior FRANZ wrote:
* Erik Hofman -- Monday 16 June 2008:
(What are the reasons to write to a file anyway?)
Writing non-PropertyList XML files, like they are used in the
traffic manager and for flight plans.
Maybe making sure the file ends with .xml could also help a lot.
Erik
* Erik Hofman -- Monday 16 June 2008:
Maybe making sure the file ends with .xml could also help a lot.
io.nas:113: writexml()
if(substr(path, -4) != .xml)
path ~= .xml;
fg_commands.cxx:1365: do_save_xml_from_proptree()
if (file.extension() != xml)
* Melchior FRANZ -- Monday 16 June 2008:
* Erik Hofman -- Monday 16 June 2008:
(What are the reasons to write to a file anyway?)
Writing non-PropertyList XML files, like they are used in the
traffic manager and for flight plans.
Writing *.stg files (adding models or adjusting elevations
On 06/13/2008 05:01 AM, Melchior FRANZ wrote in part:
The second change is in $FG_ROOT/Nasal/io.nas. It replaces the original
io.open() with a version that checks for illegal write access to
non-authorized directories. (Reading is allowed everywhere. Use the
OS' permissions to prevent that.)
It's well known that Nasal has an io module with wrappers around
fopen(), fclose(), etc. An aircraft that you install, or even
scenery objects with embedded Nasal could in the past use this
to delete the contents of your whole home directory, or to append
commands to ~/.bashrc, and thus execute
On Fri, Jun 13, 2008 at 2:01 PM, Melchior FRANZ [EMAIL PROTECTED] wrote:
FG_HOME,
/tmp/, /var/tmp/,
[A-Za-z]:TMP/, [A-Za-z]:TEMP/,
[A-Za-z]:/TMP/, [A-Za-z]:/TEMP/,
Please tell me if this doesn't work for you, or if want more. You
can add * as first entry to
On Fri, 13 Jun 2008 17:10:11 +0200, Csaba wrote in message
[EMAIL PROTECTED]:
On Fri, Jun 13, 2008 at 2:01 PM, Melchior FRANZ [EMAIL PROTECTED] wrote:
FG_HOME,
/tmp/, /var/tmp/,
[A-Za-z]:TMP/, [A-Za-z]:TEMP/,
[A-Za-z]:/TMP/, [A-Za-z]:/TEMP/,
Please tell
* Csaba Halász -- Friday 13 June 2008:
On Fri, Jun 13, 2008 at 2:01 PM, Melchior FRANZ [EMAIL PROTECTED] wrote:
[A-Za-z]:TMP/, [A-Za-z]:TEMP/,
[A-Za-z]:/TMP/, [A-Za-z]:/TEMP/,
You might consider the TEMP and TMPDIR environment variables too.
On Unix I'd even suggest to let
28 matches
Mail list logo
