[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-promo
Subject:    Re: [kde-promo] Apple Mac Boasting about how Unix is the ultimate
From:       Kurt Pfeifle <k1pfeifle () gmx ! net>
Date:       2006-05-10 23:49:04
Message-ID: 200605110144.20131.k1pfeifle () gmx ! net
[Download RAW message or body]

On Wednesday 10 May 2006 22:22, Martijn Klingens wrote:
> On Wednesday 10 May 2006 22:32, Kurt Pfeifle wrote:
> > http://klik.katekon.de/index.php/wiki/User%27s_FAQ
> > 
> > Maybe that reading will make some of your feeling go away.
> 
> "Unknown host klik.katekon.de/"

Rats! A typo; and the "wiki" + "index.php" part are also exchanged...

   http://klik.atekon.de/wiki/index.php/User%27s_FAQ

Sorry.

> > > What worries me is that you are basically exposing complete file systems,
> > 
> > Not true; "exposed" is a "file system" that contains the files belonging
> > to the klik-ed app.
> 
> C'mon, it *IS* a complete file system,

OK; then define "complete" file system.

> you even say that yourself three lines  
> further:
> 
> > Upon running, the *.cmg is loop-mounted.
> 
> Anything that can be mounted is also by definition a file system.

I didn't deny it is a file system; I even write myself in the FAQ, and
in many other published pieces things like "The .cmg is a compressed 
file system image." Not sure why you think you have discovered some
entirely new thing here...

I do object to using a term like '"complete" file system', used in a 
way that is meant to increase the perceived menace posed by using klik.

> It shouldn't be at the kernel's file system level, that is a way too powerful 
> part. One bug in mount (which is setuid), one in the loop file system, one in 
> userspace mounting flags, or one error in fstab and you are potentially 
> allowing setuid or device inodes.

True. We all will have to live with that danger. (Just like we all 
live with the dangers coming from potential bugs in your source code
that could by accident delete all our mails, or other data).

But all these potential "mount" bugs will affect you wether you use 
klik or not, and possibly in a much more severe way than via the 
consequences that come from klik using loop mounts.

> A bigger problem is that it's too easy to launch Klik images.

It is also its biggest benefit  ;-)

You decide; just weigh benefits versus perceived "problems" and dangers.

> Not to mention that the Klik client even enables Klik apps to be run from 
> things like web browsers. That's just a disaster waiting to happen, embed a 
> klik:// URL in an iframe and you need exactly one exploit in the browser that 
> bypasses permission checks.

Why? 

Assuming a browser bug will bypass permission checks. OK, then the 
klik client (the klik:// URL handler) will take over without asking 
the user first "do you want to follow the untrusted link <blah-blah>?"
-- but that very client will then pop up a message that asks the user

   "Do you want to download and run amarok-svn-nightly?
    This is a 6397kB download for suse10. It will download 
      http://debian.tu-bs.de/debian/pool/main/a/alsa-lib/libasound2_1.0.8-3_i386.deb 
      http://debian.tu-bs.de/debian/pool/main/e/expat/libexpat1_1.95.8-3_i386.deb 
      http://debian.tu-bs.de/debian/pool/main/libm/libmodplug/libmodplug0_0.7-4_i386.deb \
                
      http://debian.tu-bs.de/debian/pool/main/libm/libmusicbrainz-2.1/libmusicbrainz4_2.1.1-3_i386.deb \
                
      http://debian.tu-bs.de/debian/pool/main/m/mysql-dfsg-4.1/mysql-common-4.1_4.1.11a-4sarge2_all.deb \
                
      http://debian.tu-bs.de/debian/pool/main/m/mysql-dfsg-4.1/libmysqlclient14_4.1.11a-4sarge2_i386.deb \
                
      http://debian.tu-bs.de/debian/pool/main/libo/libogg/libogg0_1.1.2-1_i386.deb 
      http://debian.tu-bs.de/debian/pool/main/libt/libtheora/libtheora0_0.0.0.alpha4-1.1_i386.deb \
                
      http://debian.tu-bs.de/debian/pool/main/libv/libvorbis/libvorbis0a_1.1.0-1_i386.deb \
                
      http://debian.tu-bs.de/debian/pool/main/x/xine-lib/libxine1_1.0.1-1sarge1_i386.deb \
  http://www2.truman.edu/~iam504/amarok/amarok-xine_1.4.SVN_i386.deb 
      http://www2.truman.edu/~iam504/amarok/amarok_1.4.SVN_i386.deb  
      http://www2.truman.edu/~iam504/amarok/libtag1c2_1.4-1_i386.deb
   "

(I deliberately picked one of the largest recipes [in terms of the 
number of used "ingredient" packages we ever had] -- 13 .debs going 
into the amarok-svn-nightly.cmg. Don't try this particular one,
though -- the upstream amarok builds previously done by an amaroK
developer hosted on truman.edu did stop to work at one point, and 
the recipe is no longer valid).

> I might add that those are amongst the most  
> common flaws found in web browsers.
> 
> Klik should work *ONLY* from the 'shell', which in case of KDE is kicker and 
> kdesktop, and perhaps Konq in file management mode. Definitely *NOT* from 
> firefox, opera, KHTML, KMail and the like, that's just too dangerous. 

I do not see your point, and thusly can't agree with you. If there 
indeeed *is* any danger in the klik client, or in a specific klik 
recipe, or in a particular ingredient (rpm/deb/tgz) package, that 
is not increased by accessing it via the browser, and it is not 
decreased by limiting it to your definition of 'shell' access.

> > Now tell me if your bad feeling still persists?
> 
> It does. You are really trying hard to mitigate problems.

Rubbish. I did acknowledge the problems that are there. I did 
acknowledge that we are not security experts. I did ask for
help. I did welcome input.

I only tried to answer un-founded concerns. Such unfounded concerns
were e.g. you pointing to "all the risks of setuid and device inodes".

Now that you have been made familiar with klik's enforced nosuid and
nodev mount options, "you are really trying hard to" come forward 
potenial browser problems outside of klik's influence.

So be it.

Please try to find arguments that I do not need to force myself into
taking them for serious. Please also read the FAQ, now that I provided 
the correct link above :-)

> Mount flags, are set  
> correctly. The problem is that you are *relying* on mitigation. 

I don't get that argument. What do you ant to say?

> Security-wise  
> you set the permissions such that certain configurations are impossible, but 
> technically they still are in the underlying system. Hence, a single bug and 
> you have REMOTE code execution from within the browser, by *FAR* the most 
> common vector for installing spyware on Windows.

The bugs you are pointing to (potential bugs by now), are not limited
to klik; should they occur, their potential implications will concern
you much more severely than by means of klik.

We want to increase the klik security nevertheless. We want help with
that. We want to go beyond what we are offering now in that respect.
But so far, I fail to see how I could translate your comments into a
real improvement.

> Anything that has a large potential web or email attack vector is by 
> definition a major security risk. I for one wouldn't allow Klik in a 
> corporate network the way it works now,

I wouldn't either  :-) 

But I also wouldn't allow a user to "sudo apt-get install $anyapp"; 
would *you*?

However: yes, I would allow the same users to use the very same pre-
tested klik .cmgs -- not via our standard klik client, but by fetching
them via drag'n'drop.

> nor would I allow it on, say, my  
> mom's pc.

I would.

I'd rather teach her in 3 minutes how to klik a new app (and also
completely get rid of it again with one single delete action, that 
leaves the base system un-affected whatever the amount of bugs and 
incompatibilities in the libs are that are embedded in the .cmg)
than risk her "gaining" a completely unstable system running "apt-get
dist-upgrade".

It seems our choices are different. That's not bad in itself :-)

It's too late now for me. I may respond to the rest of your comments
once I find time.

Cheers,
Kurt

> > > Currently that risk seems not to
> > > be there, but I'd much rather see a file format where it's impossible to
> > > even *support* that kind of functionality in the first place, rather than
> > > relying on mount flags and behavior to filter it out.
> > 
> > I don't get what you mean here.
> > 
> > Can you point me to one such file format?
> 
> Zip? That doesn't have the notion of permissions. No way to abuse them. 
> Doesn't support symlinks, doesn't support devices. Just files. Plain data 
> files.
> 
> Still doesn't solve the problem of Klik being far too easily accessible and 
> far too easy to trick people into activating untrusted URLs.
> 
> > 
> > > Also, from a sysadmin/kiosk point of view I'd really like to see the
> > > ability to limit Klik to a predefined set of applications and/or to
> > > bundles that are digitally signed (gpg?) by, say, the IT department or
> > > the KDE project.
> > 
> > We are currently experimenting with a klik client that only accepts
> > gpg-signed recipes. Help + feedback is welcome! We are only amateurs
> > as soon as it comes to security. See here for some more details:
> > 
> > http://klik.atekon.de/wiki/index.php/Digital_signatures
> 
> I know, I read that. But that's a different client, it doesn't allow a 
> sysadmin more fine-grained control.
> 
> Some things to consider for example:
> 
> * Allow only recipes that are not only signed, but signed by people who I have 
> in my web of trust
> 
> * Allow only recipes that are signed by a handful of 'authorized' corporate 
> GPG keys
> 
> * Allow kiosk-like ways to enforce the above settings, and control them on a 
> per-user basis
> 
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on \
or temporarily stop your subscription.


[prev in list] [next in list] [prev in thread] [next in thread]