[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: