Re: KDE and security
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
Reply to: