On Thu, 7 Nov 2002 00:34, Josef Spillner wrote: > > One problem I am currently dealing with is that I want to run games under > > a different context that is denied read access to regular files (so a > > game can't send my private data over the net if cracked) and given > > read-only access to it's config files. > > Oh come on.
??? We are seeing many security advisories concerning games at the moment... > Some KDE games use KIO to transmit highscores and load/update level files. > Some games use general data such as in /usr/share/trans (and all sort of > dictionaries). /usr/share/trans is read-only public data and isn't a problem. KIO may be an issue, couldn't the games just write to a file as non-KDE games do? > In the not-too-distant future, there will be gaming services spawning > sandboxes on their own for each launched game type (which is currently hard > to do on Linux when being non-root, unfortunately - 1:0 for the Hurd here > ;). HURD is good for this, but SE Linux and other MAC systems can do the same things if the administrator configures them appropriately. > Some scan for available wallpapers, or media content of other games, at > runtime (which, via KStandardDirs, can be global or local data, mixed > transparently). This KStandardDirs sounds like something that could be an issue if the user specifies a local file. > > For /tmp/ksocket-user and /tmp/.ICE-unix, will KDE use an environment > > variable for specifying the tmp directory? If so it shouldn't be > > difficult to solve this. Also what is the point of the .ICE-unix > > directory anyway? > > I've got this one in my startup scripts: > · mkdir /tmp/.ICE-unix > · chmod 1777 /tmp/.ICE-unix > If not doing this, ICE (X11) would create it on its own and decide to > sleep() (no joke, seen on a Gnome list some time ago). This sounds like a good idea. We should probably have that as the default in the Debian packages. > > But the .DCOPserver* files are a more serious problem. IMHO the core > > code should be changed to put them somewhere more appropriate. I'd be > > happy to offer a patch if someone's interested in merging it (either in > > Debian packages or upstream). > > If it's a security problem, a Debian-specific solution is not better than > no solution at all. It is for Debian users! ;) -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
