POLARIS: Security enhancement for KDE

Various KDE 1.-4. Improvements

Source (link to git-repo or to original if based on someone elses unmodified work): Add the source-code for this project on opencode.net

Available as/for: -

I was reading some article on the web and found this article:


Basically, it describe a mechanism to restrict privileges and sandbox
any application by providing
"null priviledge"
whatever GUI dialog box needs to run for any given application.

Mainly, creating an easy-to-use transparent way of sandboxing application by default.

Maybe we could do something similar in KDE.

Since currently, most GUI application runs with "user priviledge",
which means any app can see any files in your $HOME directory
or mess with it.

I know that currently no one is really exploiting this,
but it might be an issue at some point in the future.

I know most people have backups,
but it doesn't protect against
sending your backups or sensitive data to some hackers or evil adware company in the future.

For instance, if you open an application
this application cannot read/write any file unless its allowed to,
so you have to configure which config files, shared libraries must be allowed by default.

If you want to open a file say "file.txt" via an "open dialog box",
only that file is allowed to be opened by that application for reading.

The application is allowed to write
when you enter a "save dialog".

Therefore, if you are viewing file.txt, it should not be allowed to open file2.txt
unless an explicit GUI dialog allowed the application to do so or unless you authorized it explicitly.


16 years ago

could someone please render these comments in simpler terms? (ok, i admit, i've been using linux for about 6 years but these comments lost me real f'ing quick.)
BTW, what's up with that 2nd response to this post?
1) who the f is asdex
2) why is he/she posting someone elses personal data
3) why does the supposed link provide a 403 code?
4) and just who the f is hacked.org? (whois post follows)
Domain ID:D2401528-LROR
Domain Name:HACKED.ORG
Created On:27-Jun-1997 04:00:00 UTC
Last Updated On:22-Oct-2004 22:20:51 UTC
Expiration Date:26-Jun-2008 04:00:00 UTC
Sponsoring Registrar:Network Solutions LLC (R63-LROR)
Registrant ID:20149536-NSI
Registrant Name:Hacked Technologies
Registrant Organization:Hacked Technologies
Registrant Street1:1000 Rosewood Dr
Registrant Street2:
Registrant Street3:
Registrant City:DeSoto
Registrant State/Province:TX
Registrant Postal Code:75115
Registrant Country:US
Registrant Phone:+1.2143348133
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:tek@WAVETECH.NET
Admin ID:21020961-NSI
Admin Name:Hacked Technologies
Admin Organization:Hacked Technologies
Admin Street1:8580 Hiawatha Ave
Admin Street2:
Admin Street3:
Admin City:Eden Prairie
Admin State/Province:MN
Admin Postal Code:55347
Admin Country:US
Admin Phone:+1.2143348133
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email:tek@WAVETECH.NET
Tech ID:21020961-NSI
Tech Name:Hacked Technologies
Tech Organization:Hacked Technologies
Tech Street1:8580 Hiawatha Ave
Tech Street2:
Tech Street3:
Tech City:Eden Prairie
Tech State/Province:MN
Tech Postal Code:55347
Tech Country:US
Tech Phone:+1.2143348133
Tech Phone Ext.:
Tech FAX:
Tech FAX Ext.:
Tech Email:tek@WAVETECH.NET



16 years ago

> 1) who the f is asdex

I'm asdex. Do you like my content? (e.g. http://www.kde-apps.org/content/show.php?content=6956 )

> 2) why is he/she posting someone elses personal data

Which one's data?

> 3) why does the supposed link provide a 403 code?

Because you have clicked onto it? Next time you do this it could be that afterwards one process more is running on your computer.

> 4) and just who the f is hacked.org?

Who the f are you?




16 years ago

Could someone please render these comments in simpler terms?

He's joking around to explain his point
that's it.

1) who the f is asdex

Some dude!?

2) why is he/she posting someone elses personal data

It's probably some fake data,
to make the story more funny?

3) why does the supposed link provide a 403 code?

It's probably a "bad url",
to make the story more funny?

4) and just who the f is hacked.org? (whois post follows)

Don't freak out! =P

He was just making fun of how Microsoft virus spread up
by using the latest xpdf security glitch as an example,
that's about it. I think...





16 years ago

Just quoting some 'DrStupid' folks:


One might be able to set something like this up with the -u option to kdesu,
thus running an untrusted app under the "nobody" account.
Or a special "sandbox" user created just for this purpose.

Going further, one could imagine a graphical frontend to setting up
a chrooted environment in which suspect apps could run.




16 years ago

Ideally, 'nobody' account is an interesting compromise,
but you might not want to have
Konqueror having the same privilege
then Kate, KOffice, KPDF or some games.

So, really priviledge should be tuned
per application.

So, we actually need one account per app or per context,
the small problem is that it clutter

Also, the other problem is that
chown'ing around requires root.
There's currently no explicit way
of chown'ing to a sub-level privilege
thanks to current POSIX implementation.
So, some of the POLARIS component
would have to run as root or similar.

This means we should have:

- a list of allowed files to be read/write/execute by default.
- a list of protocols/port allowed by default
- a list of shared lib required
- a list of currently used files

For instance, if you could use a PETS name for konqeror
when accessing local hard disk and another one for Internet.

One way, would be to implement a
sub-class authorization widget
or an 'authorization' decorator design pattern
for GUI widget such as
open dialog, save dialog,
print dialog, list box, radio, option, checkbox, etc.

Maybe, those widgets, for instance
list box should have a different
background color to indicate as such.
Thinking about how the yellow background
in Firefox indicate an SSL context.




16 years ago

Would that not be one user per app per context per user? It'd be dangerous if any one user could go around opening .kwd files belonging to any other user merely by selecting it in KWord's open file dialogue. Even more dangerous if they can save it simply by selecting it in KWord's save file dialogue.



16 years ago


I'm the new Limda-Virus exploiting another xpdf vulnerability. Since you have viewed this PDF (brought to you by a google search) and your PDF viewer runs with all privileges, I'm posting your email account data to kde-apps.org.

Email account data:
user: asdex
password: jhtzhn
email: asdex@freshmeat.net

A random selection of your sent-mail folder will be posted at kde-look.org

Pleas help me spread by clicking onto http://hacked.org/linux-wlan-howto.pdf

Lesson learned? ;-)

* A Webbrowser should not need to access ~/Documents
* A PDFreader should not have rights to access anything other than the actual PDF.
* ...



16 years ago

This would be a great feature in KDE 4. You should send an email to one of the KDE dev mailing lists about this


Be the first to comment
File (click to download) Version Description PackagetypeArchitecture Downloads Date Filesize DL OCS-Install MD5SUM
*Needs pling-store or ocs-url to install things
0 Affiliates
updated Jan 24 2005
added Jan 24 2005
downloads 24h
mediaviews 24h 0
pageviews 24h 0