-devel-games: this summarizes feedback from the bug, which was pretty
similar to what you said: everyone wants a "this is not safe, do it
anyway? [Y/N]" prompt, rather than knocking out cl_allowDownload altogether.
Please reply to both the list and the bug.
On Tue, 04 Sep 2012 at 15:42:21 +0200, Markus Koschany wrote:
> In practice this would force players to download custom maps and even
> new versions of base maps manually from more or less trustworthy servers.
Yes, I do see the problem. If people are willing to download
potentially-executable code from arbitrary sources, then there's nothing
we can do to make them secure.
It's a pity there isn't a distinction between executable and non-executable
game content - if you could auto-download PK3s, but those PK3s were flagged
as "not to be searched for QVMs" somehow, then everything would be secure -
but there isn't, and realistically, this isn't going to change before
wheezy.
Unfortunately, some use cases for auto-downloading do rely on executing
downloaded code:
> For example Ubuntu players are playing with version 0.8.5 at the moment
> and my Debian server is running 0.8.8. If cl_allowDownload was
> permanently disabled all players which run an older version wouldn't be
> able to join my server although they only had to download the
> pak6-patch088.pk3.
As far as I can see, my proposal would not break this. Auto-downloading is
possible if the server has sv_allowDownload true and the client has
cl_allowDownload true: my proposal was to knock out cl_allowDownload, but
leave sv_allowDownload working. Older clients could still download your
pak6-patch088.pk3, but Debian clients on a future 0.9.0 server would not
auto-download.
If client auto-downloading was allowed but bytecode in auto-downloaded
PK3s was prevented from being being executed, this use-case would still
fail for updated clients, though: upstream's pak6-patch088.pk3 contains
updated cgame and ui code.
(Debian's doesn't, because we don't have a Free compiler for it; we run
equivalent native-code game logic from the openarena package instead.)
> * Automatic downloading is disabled on the first start thus OpenArena is
> secure by default.
This is already the case; the default has always been cl_allowDownload = 0.
> * You could also move the menu option for auto downloading to the
> bottom and improve the description. "Warning: Enabling of auto
> downloading *could* lead to security implications. Worst case:
> Execution of arbitrary code. Please visit <link to the Debian Wiki>
> and carefully read about the alternatives *before* you enable this option.
Unfortunately, the Quake 3 engine's UI toolkit is not very good at
displaying significant amounts of text (it's done in a very low-res style),
and the text I put in the confirmation box comes out in all-caps anyway,
so the best I've been able to do so far looks like this:
/ Auto-download? \
\ YES/NO /
WARNING: this is a security risk.
More information: <http://deb.li/Q3DL>
I've uploaded 0.8.8-7 to experimental with this change. If you (for
plural values of "you") can improve on this UI or the wording on the
referenced wiki page, please do!
The relevant code change is:
http://anonscm.debian.org/gitweb/?p=pkg-games/openarena.git;a=commit;h=eed3e6469
On Tue, 04 Sep 2012 at 21:03:48 +0200, Stefan Potyra wrote:
> Maybe there's another measure to mitigate against some effects of malicious
> downloads: Can access of ioquake3 (and games using it) be restricted
> somehow? (apparmor or selinux comes to my mind, but I must admit that I don't
> have much clue with that).
Not for Debian 7, and not by me, but if someone else wants to
do this for Debian 8, great. (This won't protect anyone who isn't using
the relevant LSM, though.)
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
