Bug 523694

I would say: do not allow clicking on URLs.

yast2-gtk -> mmeeks

Yep, it also opens up a xterm when you press Ctrl+Alt+Shift+X. 8-) And I can think of a few other simpler ways than using Javascript (?) for someone running yast2 as root to put the system to its knees.

If we're going to get tough on this, then we should do it all the way. But is there at all any way for an administrator to let the user run a particular X program as root without giving it grand access to the system? Is setuid still being used? Can't you easily make a X server program crash (and exploit it?) if you own the X client?

Related: bug 464074

Michael, this seems like an interesting topic. Do you want to pronunciate on it?

I guess I just realized what Marcus is thinking about. He is not talking of cases where the system admin gives the user access to run the software manager (expectations of security here seem unwarranted). He is thinking of the person who crafts a package in which he provides an URL with the intent of exploiting some Firefox vulnerability as the oblivious user visits the website.

My first instinct is to say that someone who has the ability to deploy packages can easily exploit its users. But of course the user expectation is with regard to the installment of the package, not with the mere use of the visualization box.
The person trusted to package a given software can also be tricked by the vendor. But the same mantra applies: you have to trust the vendor anyway.

By the way, as a private user, I personally don't care much about these concerns over privilege escalation. OpenSuse is a desktop OS so that tells us most users will only have one account for the household. In other words, if you gain access to that account, you get access to all the important data of the system. Who cares you can't corrupt the system files and make the system inoperable. The only thing important for the desktop user is that his data be secured, and Linux binary security system won't help him.
Some people made a big deal out of Linspire running the system as root, but that is only a red herring over the important problems of restricting applications to their proper scope and certifying vendors. In economic lingo, the marginal cost of preventing superuser access after gain of user access is close to zero, so we should concern ourselves only over the marginal benefits.

This is mostly a side rant, but it does constrain the problem to SLE, and the enterprise environment.

We can't run gnome-open as the user who initiated the session (can we?), but we definitively should make it easier to copy the link for those users who feel conscious about running Firefox as root.

Btw, Marío I couldn't help but make the connection to your feedback on EatFeed, my RSS/Atom hack of a reader. I guess from the Spanish name. We are working on a relift of the software manager UI; if you'd like to throw your 2 cents, check the simple procedure over bug 464909, comment 3, and send me an email that I will forward it to the other guys.

Heh - so, I'm no security paraniod ( ask Marcus ) - but I too am concerned with running as big a beast as firefox + plugins + ... as root.

I guess, ideally we need some IPC that allows us to launch a firefox window inside the user's process - though we don't have access to the session bus at that point sadly.

So a 'right' solution might be to propagate the DBUS_SESSION_BUS environment through to the y2base user, and have some auto-activating magic to launch a URL that works over the bus; but that sounds like a chunk of work :-) [ presumably 'gnomesu' would need changing ] and presumably there is also some other theoretical security issue with letting root talk to the session bus ;-)

I guess the easiest thing is to #ifdef out the feature (sadly).

Sorry.

Maybe there are serious concerns about opening those links to webpages as root, but I think you guys are only reacting on prejudices built on past sincere concerns over security, and not thinking this through. Think about it: if you can't trust the vendor or packager from providing a malicious link, you're already screwed because he has unlimited means to, and more reasonable and effective ones, to hack into your system. Now, the user could be oblivious to the fact he is running the browser as root and continue to surf the web, which could be problematic (I personally 'd contest that root vulnerability warrants any extra concern on a single-user desktop system), but we could always gift the user with such a prompt as (once a link is pressed):

  "You are running the software manager as the ADMINISTRATOR."
  "Using the web browser as root is strongly unadvised."
        [ Cancel ] [ Copy link ] [ Open link ]

By the way, we also open nautilus as root when the user clicks on a file; is that merit of reform as well?

   ------------  / / -----------

I think there sheds light in the tunnel though. gnomesu, like ordinary "su", seems to keep the shell environment intact. That means we have access to such variables as USER and USERNAME (anyone know what the difference is?). De-escalate from root to an ordinary user is possible, so maybe we have found an alternative course of action here?

So I was using "gnome-open" which seems unable to find its tail when run under "gnome-su" (some display access denied error), but firefox runs fine, so let us use that one.

.

what about not allowing to click on URLs.... ?