Activating and deactivating privileges

Hi all,
Here again I’m writing a su question that probably’s been answered many times, but search didn’t help. So next my noobie question:

When I’m normal user, GUI asks me for a root password sometimes, so this is a hidden “su” in a form of GUI. So, I become root then, or I’m “almost normal” user except that I can execute that command? Everyone says using GUI as root is not, not good, in any case NOT.
Plus i’m connected to the internet at the moment I’m granted privileges. But since KDE or Gnome or any other thing work like that, I don’t know if this is a problem.

Ok then, at the moment system dialog is closed, do these permissions go away, and all is fine just like after the boot of normal user? When the Yast is opened, is system more vulnerable?


Well, technically you don’t become root, you’re ( temporarily ) getting root permissions.
I guess you misunderstood something: people warn you not to run a desktop environment as root. Doing so means that everything ( incl. browser ) runs as root. When kdesu or gnomesu are invoked to perform system stuff (f.e. run YaST) the permissions are only for that program, the rest of your desktop runs as your normal user,. As soon as you close the associated program, the root permissions are no longer there,
And no, when YaST is open wih an internet connection, there’s no security risk. Without internet connection no repos, no network config, no network services etc.

Well then, this is certainly a very clever way. For servers, should be connected 24/7 indeed.
(Ok, I guess there could be risk of a keylogger, but they are multiplying on Windows anyway.) Worries aside!
Thanks for your time

gave out too much reputation today

Although everyone, everywhere on every different distro and OS understands that unnecessarily high permissions is a security issue and the first account created for all OS is exceptionally so (eg root on Linux, administrator 500 on Windows), there is broad disagreement how and when to loosen security for Users, because normally forbidden tasks need to be done from time to time.

So, for example some Linux distros don’t allow Users to “su” to root at all which is when the User can elevate to actual root.
Other distros have severe restrictions even running “sudo” configured for impersonating root (think of you’re still “you” but doing things on behalf of root).
Even on MSWindows the “Administrator” account with UID 500 which exists on every machine is now hidden by default, and UAC has been implemented which is sort of like our Linux sudo.

Here in openSUSE,
We have a fairly relaxed attitude about invoking elevated permissions. If you understand what is happening and follow some simple rules, I don’t know that anyone has actually been compromised.

When you provide root credentials in openSUSE, that’s normally in a graphical console like YaST or a text console/terminal, windowed or not. Your elevated permissions are limited to what happens in that console… You might run an application directly, or you may invoke another “child” application which inherits elevated permissions. When you close the parent console, all child consoles should automatically terminate as well.

So, that’s a couple major rules to keep in mind…
Keep an eye on what is happening in those consoles that invoke elevated permissions and be aware if anything unexpected starts to happen.
And, most importantly… Close elevated consoles when you’re not using them because although it probably isn’t easy to take over a console, why take any chances.

As for Internet hackers somehow invoking or hijacking an open elevated console…
No one has yet reported such a hack.
Someone would have to at least pose and possibly advance a theory how such a hack might be accomplished before people would look at the possibility closely.
In general, the way various sessions and proc trees work should prevent stuff like, for example someone in a Web browsing session hijacking a running console on your machine. Long ago, there used to be support for, and then exploits associated with web browser application vulnerabilities, but many years ago people suddenly decided that web browsers shouldn’t have that kind of access to a machine. It’s still possible to open consoles in a browser, but those should be limited in their security context to the web browser itself. In fact nowadays, typically any command line functionality through a web browser should be controlled by APIs. Note that this is different than a “local logon” over a remote connection like SSH, which is always dangerous.

If you do want to tighten up security though…
Although I don’t know specifically of an AppArmor or similar policy-based security configuration that I can recommend(but may exist)…

  • Consider making the root account’s credentials different than your User accounts.
  • Consider inactivating sudo as a means to elevate permissions