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
Re: KDE and security
On Wednesday 06 November 2002 13:55, Russell Coker wrote: > I think that these files should be created in a subdirectory so that they > can be easily tracked, controlled, and removed when not needed. Should be doable. > 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. 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). 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 ;). Some scan for available wallpapers, or media content of other games, at runtime (which, via KStandardDirs, can be global or local data, mixed transparently). > 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). > 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. Josef -- Free operating systems. Free software. Free games.
Re: KDE and security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 06 November 2002 05:55 am, Russell Coker wrote: > 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? Speak to the kde-kiosk guys about this. It's a question that comes up everyonce in a while, but I don't remember the answer. IOW, you could probably go through their list archives. > 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). See above. > While we're at it, the error handling in QT could probably be improved. If > you are denied access to create ~/.qt/.qtrc.lock then trying it four times > is not going to get you access... IIRC, this is because of crappy nfs issues. I.e., it is quite possible to be denied access the first couple times and allowed the third, simply because so many nfs implementations suck :-( Note that I am explicitly including linux's here... - -- A mouse is a device used to point at the xterm you want to type in. --Kim Alm, a.s.r -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE9ySUcEHLN/FXAbC0RAlolAJ0blnfiaxiCuG2p3lV9CWvsHgNhcACg8PG7 KkssMsdYynPZ631DGKMZCp8= =CYiu -END PGP SIGNATURE-
KDE and security
When logging in to KDE a file .DCOPserver_hostname__0 is created in the home directory and a symlink named .DCOPserver_hostname_:0 is created to point to it. There are several other files that have been used by different versions of KDE, there was .MCOP-random-seed and there were a few others. I think that these files should be created in a subdirectory so that they can be easily tracked, controlled, and removed when not needed. 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. I've currently got my ~/.qt and ~/.kde directories set to the type user_games_ro_t so that games can read them but not write them (and regular processes can write them). However the games still need access to /tmp/.ICE-unix (which is a bad idea anyway for security reasons), ~/.DCOPserver_hostname__0, and /tmp/ksocket-user. 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? 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). While we're at it, the error handling in QT could probably be improved. If you are denied access to create ~/.qt/.qtrc.lock then trying it four times is not going to get you access... -- 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
