Automating Your Desktop with KJSEmbed

Ian Geiser at SourceXtreme, Inc has posted the second in a series of articles on development with KJSEmbed. KJSEmbed is the KDE JavaScript engine with bindings for Qt/KDE. These bindings allow people to create scripts that can tightly integrate into KDE quickly with simple JavaScript. This article covers how to use the DCOP API from KJSEmbed and sports a simple demo script that shows off how to use this API. This article covers the bleeding edge version of KJSEmbed from CVS because of new features that were added soon after the release of KDE 3.2. The goal is to give people an overview of the new technology and to allow developers to become aware of the new scripting options. Both developers and non-developers are encouraged to check out the new article.

Dot Categories: 


by KDE User (not verified)
by anon (not verified)

Any chance for unstable kjsembed releases or even snapshots from cvs (that rely on kdelibs 3.2.x not kdelibs-cvs)?

by Ian Reinhart Geiser (not verified)

this will work with kde 3.2. its a matter of getting a source snapshot of KDE bindings from head. We are currently debating an release in a few weeks to help people who wish to start using KJSEmbed now. In fact I really want a release so I can add this to

It needs latest CVS because I fixed a bug where QBoxLayouts didn't work. Stay tuned. Worst case Rich or I can make this available on our websites.

by Shulai (not verified)

While I'm pretty confident about KDE developers, I wonder how close this mimics WSH and Windoze scripting, and if this could raise security concerns...

For example, I believe JS embedded in e-mails should be able to do stuff into the mail itself, but never be able to access mail client functionality (Addressbook access, harvest address from another mails, sending mails, etc.), and of course shouldn't be able to access functionality from another parts of the system.

by Spy Hunter (not verified)

No, JS in emails should not be allowed (and I'm sure it won't be by the KMail developers). Sandboxing sounds nice in theory, but it's impossible to get perfect in practice. It's a humongous security hole waiting to happen and there's no good reason for it. Mouseovers in your HTML mail are not a good reason. If you want to send something that includes code, send it as an attachment and make people execute it manually. JS in webpages is bad enough, but at least you have to go and visit a site to execute the code, so you have some say in what does and doesn't get executed. If JS in emails got executed automatically, anybody could make people execute arbitrary JS code just by sending it to them in an email and waiting for them to view it. Any security hole in JS immediately becomes remotely exploitable on an arbitrary target system, with no user action required other than checking email.

by fprog (not verified)

What about website abusing KJSEmbed to run malicious JavaScript/DCOP
to install spyware on your KDE box ?

For instance, having your spyware run everytime you run KDE...

It's nice to see features but I see some problem
here if not done security wise.

What about root users running KDE viewing some website or email
and then getting infected without notice ?!

Infected like installing a SPAM server, installing rootkits, etc.

Be careful!

by Anonymous (not verified)

What about not working as root at all?

by GaRaGeD (not verified)

Come on, u dont need to be root to have installed spyware, what about rewriting bashrc, or something like that ??

Get the idea?

by Anonymous (not verified)

How will rewriting a bashrc of a user allow to install a rootkit?

by security101 (not verified)

echo -e "
hex version of #!/bin/bash
if -e ~/run then
wget ... >>/dev/null
curl ... >>/dev/null
chmod 755 ~/run
" >> ~/.bashrc

Rootkit are to be run as non-root to gain root,
install crapt in some case, open ports, remove all trace,
make your box a slave...

by Simon Edwards (not verified)

The security risks associated with KJSEmbed are no greater than those for Perl, Python or any other programming language. KJSEmbed merely uses the Javascript interpreter which is traditionally used by Konqueror. KJSEmbed is totally separate from Konqueror, KHTML and KMail. Nothing has changed in that respect.

Everyone claim down. The KHTML developers haven't lost their minds (anymore than usual =) )


by fprog26 (not verified)

My goal wass not to spread FUD or fear,
I just want to make sure that people are security concious period.

I admit, I haven't read the entire KDE CVS to look how it's implemented,
just read the article and few about it.

Perl or Python are executed from webpage on the server not locally (no risk),
while JavaScript is executed on the client not on the server.

Maybe with a KIO-Fuse or io-cmd slave...

Now, how you get KIO-Fuse from Konqueror, you probably can't...

However, someone else wasn't that cautious:

click me (not really!)

"KJSEmbed merely uses the Javascript interpreter
which is traditionally used by Konqueror."

Okay, now if it uses the same "interpreter"
how does that same "interpreter" is isolated from DCOP ?
Someone pointed into the "sandbox" feature, how does it work?

Is there any regular "testing" done upon every release to ensure
no security risk are presents?

Mainly DCOP calls don't work in Konqueror/KHTML/KMail?

The best way is "education", show, describe, write webpages
describing why it's "impossible".

Bugs appears often when people discover them
and wouldn't be please no more than anyone else 2 years from now
when a bug would allow such... and people exploiting it!

For what its worth, I love KDE, I think it's a great environment,
but I think it's worth being a bit more cautious about what's get in.

by Ingo Klöcker (not verified)

JavaScript is never and will never be interpreted by KMail (or more precisely by the KHTML part that KMail uses).

by Marc Ballarin (not verified)

You are automatically associating Javascript with Internet. This is wrong, however.
Javascript is just a scripting language like any other. Absolutely no differences - except, that JS is often used in webbrowsers. The security problems are only caused by this kind of usage (untrusted sources and the resulting need for error prone sandboxing).

In the case of KJSembed, JS is used as a regular local scripting language. All scripts have to be on disk, and are executed like any other script or programm. KJSembed is a separate interpreter, having absolutely no connection to KHTML or Kmail. It is used just like Bash, Python or Perl by setting a script's first line to "#!/usr/bin/kjsembed".

Of cource, you can write a malicious script using KJSembed, just like you could write a Bash script doing "rm -rf ~/" or a C Programm doing the same.

by fprog26 (not verified)

Thanks for the clarification.

by Ian Reinhart Geiser (not verified)

I know the about your urge to promote fear of any platform that KDE supports, but please refrain from outright lies.

1) KJSEmbed scripts must be run of the local file system. Since you obviously have no clue how KDE operates Ill let you know that KMail attachments, Webpages etc. are not a local file system.

2) KRun (the thing that starts stuff up) cannot run scripts on click*. This is a bug, it will be able to run scripts in 3.3 that are marked executable by the file system. So again you lose, a script must be downloaded, and chmod +x to even run.

3) KDE doesn't introduce any new holes that UNIX has not had for the last 30 years in respects to shell scripts. We are just allowing GUI applications to be automated the way CLI apps have been for years.

So please in the future put your FUD somewhere more useful than KDE. We have no time for ignorant chicken little's who love to yell the sky is falling as loud as we can.

*This is not totally true but its not worth explaining the details of that here, refer to the kde-core-devel list.

by Ian Reinhart Geiser (not verified)

It's only similarity is that it is a script engine.... please research this stuff before posting or go back to slushdot.

This adds absolutely no more risk than say python, perl or even bash shell do to linux. How many python viruses do we have out there? Oh in the last 30 years how many shell viruses have we seen? Hmmm maybe 0 at last count? You might think if there where a way to spread a script virus on unix they would have found it in the last 30 years, right?

All in all while your FUD is amusing to me personally, it's not helping the spread of our platform. If you wish to give input please, I beg you to at least research and learn the architecture before spreading fear and doubt about the platform. I have been fighting these lame arguments with dcop for years, I would think people here like KDE enough to not spread FUD like this.

by The Badger (not verified)

It's easy to understand why people might be concerned having only read the news item. Take this extract:

"These bindings allow people to create scripts that can tightly integrate into KDE quickly with simple JavaScript."

Alarm bells may be ringing at this point for some people as they imagine Web pages in Konqueror offering the sort of "integration" Microsoft are well known for.

"This article covers how to use the DCOP API from KJSEmbed and sports a simple demo script that shows off how to use this API."

Note that without an understanding of how this JavaScript gets run (remembering that for most people, JavaScript runs in the browser), and with no mention of sandboxes in the face of this DCOP integration, the casual reader is going to be slightly concerned.

Now I know that people have to read your article to understand what's really going on here, and I haven't even read your article yet, but then I do know what KJSEmbed is about. The news item could be the first many people have heard/read about your work - I'd argue that a better first impression could dampen down some of that unnecessary criticism.

by Ian Reinhart Geiser (not verified)

And by that logic is perfectly for me to walk into a crowded theater and without looking for any fire alarms i should yell as loud as possible "we could all die in a fire here because there are no fire alarms!"

please, don't promote your own knee jerk reactions. you not only look foolish, but you scare people who may have less of a clue about what is going on than you. This is truly a disservice to Open Source because you undermine the platform by spreading FUD that can propogate for years.

by The Badger (not verified)

I don't follow your "logic" at all. Remember that news items like this one get syndicated widely, either via RDF/RSS or by page "mining". All it takes is for someone to see a badly presented/summarised piece of technology in a news feed and they're going to react exactly as people have in the earlier comments.

All I was doing was explaining the phenomenon, but if you want to throw your hands up in disbelief every time it happens, feel free to do so!

BTW, a more apt analogy is you meeting a group of strangers, introducing yourself with the phrase "I eat turtles" (when you do not and never have considered doing so) and then being surprised that you're subsequently known as "the turtle eater".

by Ian Reinhart Geiser (not verified)

well it revolves around the central issue that you refuse to understand what you are talking about... thats all.

this isn't slashdot, we can read the articles before we respond.

by Mathieu Chouinard (not verified)

>this isn't slashdot, we can read the articles before we respond.

This one made my day ;)

by David (not verified)

"Alarm bells may be ringing at this point for some people as they imagine Web pages in Konqueror offering the sort of "integration" Microsoft are well known for."

I can understand well reasoned but ill-informed comments. This is just bollocks. Try and understand how Microsoft implements scripting first. It doesn't have to be that way, and it won't.

by michele (not verified)

> How many python viruses do we have out there?

At least one ;)

by Ian Reinhart Geiser (not verified)

you forgot the most common unix virus though.

i have to admit in the last 21 years on a computer ive seen more Amiga viruses than Unix ones =) The point i was attempting to make is how many viruses have you _seen_. Id be hard pressed past trojans installed as parts of root kits that no-one has seen these in the wild.

amusing none the less.

by David (not verified)

Scripting like this is no more of a risk, and will add great functionality. Please don't confuse this with Windoze scripting. Microsoft in their infinite wisdom decided to expose the whole of Windows to the outisde world through scripting and ActiveX. That should not give scripting itself a bad name.

by Ian Reinhart Geiser (not verified)

IMHO the largest problem with windows scripting is their lack of concept of the execute bit. Because of this they treat every file that is a script as an executable. So click on a web link with a exe it runs... click on an exe in an email, again it runs.... scary man.

KDE has a sane group of developers and Unix architecture makes it easier for us to do things right. We can make the scripts easy for users to use, but harder to shoot themselves in the feet with.

The only thing we have to fear from scripting integration in KDE is increased usabilaty and more functionality that will make things like KDE prime time!

by Roger Oberholtzer (not verified)

Tcl has a version that can be loaded into a browser so you can
embed tcl in your code for client-side execution. The Tcl guys thought
about this and made it so that the Tcl code does not allow any file system
access. In fact, there is a list of things that are turned off. The user must
turn on the things that will be tolerated. But the default is that the worst
the code could do is destroy it's own window.

I would suggest looking at the Tcl 'safe interpreter' layout for useful pointers in this respect.

by Evan "JabberWok... (not verified)

I think there has already been sufficent research and implementations of secure and sandboxed javascript interpreters. :)

by The Badger (not verified)

Yes, but Safe Tcl has been around for *ages*, whereas a lot of people only wised up to sandboxed execution well after Java came out.

On another subject related to undone homework, I'd like to refer you to RFC 1521 ( where a search for "security considerations" will provide some interesting insights. Section 7.4.2 is especially interesting in the light of recent vulnerabilities in various PostScript viewers (

Of course, the most interesting thing about RFC 1521 is the date. I guess that all those "sufficient research and implementations" were all in vain.

by Ian Reinhart Geiser (not verified)

I would suggest maybe going out on a limb and researching before you speak, but hey I'm pragmatic, what can I say.

a) This is not in a browser.
b) We have the ability to "create a list of things to turn off"

This isn't rocket science people.