[kde-linux] KDESU doesn't work again with 4.10

[Duncan]

James Tyrer posted on Thu, 23 May 2013 15:28:08 -0700 as excerpted:

> Following up on this.  I find that there is a great mystery which I
> presume is a bug.
> 
> Your 'desktop' file works when it is in a menu.
> 
> Specifically, there is a menu item under System that correctly opens a
> filemanager window as root using KDESU.  However, if you drag this from
> the menu to the DeskTop file and "Copy" then it doesn't work.  The KDESU
> window pops up and I enter the password correctly, but the filemanager
> window NEVER shows up.  :-(.
> 
> Thanks again for trying to help.
> 
> So, I guess that I will stick to my work around till somebody fixes what
> appears to be a bug.

IIRC/AFAIK it's not a bug, it's a security measure.  I'm fuzzy on some of 
the details but some time in the late kde-3.5 era, shortly before kde4 
came out IIRC, there was a big hubbub about the security of *.desktop 
files located on the desktop.

The problem was (IIRC) that *.desktop files, similar to *.lnk aka 
"shortcut" files in the MS Windows world, are /too/ configurable, 
allowing the icon and name displayed to have nothing to do with the 
command actually run, if so configured.  Combined that with people often 
downloading content from untrusted parts of the net directly to the 
desktop, and it's a recipe for a serious security issue, since at least 
in theory, wherever they were downloading the file from could say it was 
for example "The Gimp" and have the appropriate icon for the gimp 
configured to be displayed, but instead, the actual command run could do 
something entirely different.

This is *PARTICULARLY* a problem with super-user required commands, since 
then the command could (barring a strict SELinux or the like setup) do 
literally anything on/to the system, including a rm -rf /, or sfdisk ... /
dev/sda, or...

So the major desktops (including kde) fixed the security issue by 
restricting what ordinary *.desktop files could do when they were on the 
desktop.  This is where my understanding goes fuzzy, as I /think/ there's 
some way to authorize *.desktop files so they still work, that avoids the 
danger of executing random files that simply happen to be downloaded to 
the desktop or whatever, but I was never clear on how that all worked to 
begin with, and of course now, I'm writing from memory about a security 
issue that surfaced and was fixed several years ago now, so even some of 
the details I did know are likely gone.

But my strategy in such cases is to file away enough information about it 
in my head to spot the situation should I come across it later, and to 
google up an answer, should I badly enough need it to work that it's 
worth the investigation.

...

Which seems to be the case here.  A quick google turns up some articles 
on the subject.  I didn't refine the google enough to weed out what 
appear to be a bunch of false positives as well, but at least the top hit 
seems to apply, and scanning down the list I see at least one more on the 
first page from about the same time frame (2009) that looks to be related 
as well.  I'll let you read those and then refine the search further and 
go deeper, if you like.

My google:

http://www.google.com/search?q=linux+desktop+file+execution+vuln

The top hit here (in case yours is different... watch the link-wrap):

https://cubist.cs.washington.edu/Security/2009/03/13/linux-desktop-
security-vulnerabilities/

Turns out the first thing to check is the executable bit.  See if setting 
that lets it run as expected.  (On most desktops the security bit would 
be reset when dragging/saving the *.desktop file to the desktop, so it 
couldn't be accidentally clicked to run, without deliberately setting the 
executable bit, first.)

Actually, that makes more sense to me now that when I read about it back 
then (I think I was missing the fact that the executable bits would be 
reset by default, so I couldn't see what would stop it from running, or 
how simply checking the executable bit on the file before allowing it to 
run could possibly make the difference between a secure solution and an 
insecure solution).  So I'm not so fuzzy on it, any more. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman