As Opensuse uses systemd I thought this should be known to you all.
So much for linux security huh?!
I did not read any details of this “machinectl shell”, but there are many tools that are SETUID root apart from su.
henk@boven:/usr/bin> ls -l * | grep rws
-rwsr-xr-x 1 root trusted 56392 25 jun 11:27 at
-rwsr-xr-x 1 root shadow 63368 27 sep 2013 chage
-rwsr-xr-x 1 root shadow 50584 27 sep 2013 chfn
-rwsr-xr-x 1 root shadow 41400 27 sep 2013 chsh
-rwsr-xr-x 1 root trusted 55792 19 jan 2015 crontab
-rwsr-xr-x 1 root audio 43944 5 jul 21:34 eject
-rwsr-xr-x 1 root shadow 19272 27 sep 2013 expiry
-rwsr-xr-x 1 root trusted 31504 29 mei 22:39 fusermount
-rwsr-xr-x 1 root shadow 67072 27 sep 2013 gpasswd
-rwsr-xr-x 1 root root 44248 5 jul 21:34 mount
-rwsr-xr-x 1 root root 36616 27 sep 2013 newgrp
-rwsr-xr-x 1 root shadow 51200 27 sep 2013 passwd
-rwsr-xr-x 1 root root 26656 13 jan 2015 pkexec
-rwsr-xr-x 1 root root 31744 5 jul 21:34 su
-rwsr-xr-x 1 root root 155112 9 mrt 14:59 sudo
-rwsr-xr-x 1 root root 31680 5 jul 21:34 umount
henk@boven:/usr/bin>
The important thing is if they are designed secure enough and programmed secure enough. That includes of course asking for credentials (the root password) or not.
E.g,:
- su asks for the root password;
- sudo is configurable in this aspect and thus can made as unsecure as one likes;
- mount is designed for doing only one task (which increases the inherent security) and depends on a parameter in the fstab (that should only be possible to be set by root);
- any other SETUID root program should be examined for more variants.
The problem lies IMHO in the last case. Every now and then there pop up new cases that are mostly presented as increased usability and thus have the security switched off. Like PackageKit that lets a normal user install newer versions of installed packages without having a big sign: Take care, this is a new security hole compaired against earlier practise and this might not be what you want. This “machinectl shell” will be another one. Advertised as “all singing all dancing” whitout any “use at your own risk” warning about the security aspects.
BTW, beside SETUID root, there is another way to use a root owned process as end-user: client/server. That is e.g. the case for Network Manager. Another method, but the same concerns apply.
On Mon, 31 Aug 2015 03:06:02 +0000, Sagemta wrote:
> As Opensuse uses systemd I thought this should be known to you all.
>
> http://tinyurl.com/ogzy3lu
>
>
> So much for linux security huh?!
And what makes you think this is/will be any less secure than su is today?
Jim
–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
These people are mad, they are just utterly insane.
They want to put everything under very lengthy commands. There is also a command for going into single user mode that you routinely forget the moment you see it. It is too long, and you can’t understand and learn.
init S or whatever doesn’t work anymore.
su
vs.
machinectl shell
These guys (I wanted to call them kerels in Dutch because they are clearly not women) just want to drag anything and everything into their own cozy little world where they can claim dominance and reputation share. They just want to own you. It’s that simple. They are power hungry.
Let’s call it a hostile corporate takeover.
Henk,
Thanks for restoring my faith in Linux. Also for showing this to me in a different light. So IIRC this machinectl shell will be in there like Packagkit(sort of) yet can be ignored or not used by the user. In essence the user would have to invoke it like Packagekit.
That said my fears that’s what I’ll call it was that somebody could turn this into a Linux form of windows .exe . As such my fear is unwarranted did I get that right?
Jim,
That fear I listed in my reply to henk was & in a small way still is why me to state what I did.
I maybe running the risk of rule violations here but the NSA is IMO looking for any way possble to get into every computing device there is. Also and I do state this is my opinion but if they’re not in already in every device then the NSA or its ilk think will be in cahoots with anyone they think will help them achieve this.
Let us out it a bit different.
By using any of the methods available to do things as root, one must have trust in those methods (and understand what they do). So e.g. you must trust any of those SETUID programs I showed above. Now, the simpler these programs are and the longer they exist, the more chance that they have no security flaws (any more). Thus my trust in su (existing since the beginning of Unix). Somewhat less in sudo (exists only since the 1980/90s, I am not sure, and being more complicated). etc.
Thus I, like you, will distrust anything new here. And maybe not use it, or even not install it (like Packagekit). My main concern being the fact that, like in the Packagekit case, it is not clearly anounced that it allows things that where not allowed before the program was used (simply because the devs think that what they see as an advantage is of course an advantage, they fail to understand that their feature is a bug to others). If you know it is there, you can act.
In the case of systemd, we have to wait and see.
- is there proper anouncement that a new, possibly dangerous, feature is added to systemd;
- can it be switched off/not installed (and maybe it is switched off by default);
And I realy doubt that the distribution will stop providing su when this systemd feature is introduced. They didn’t stop providing su because sudo includes it’s functiionality either. And the GNU version of su will be available in source for a long time to come. so many will be able to build and make it available it in the future.
On 2015-09-01 09:56, hcvv wrote:
> And I realy doubt that the distribution will stop providing su when this
> systemd feature is introduced. They didn’t stop providing su because
> sudo includes it’s functiionality either. And the GNU version of su will
> be available in source for a long time to come. so many will be able to
> build and make it available it in the future.
I doubt that “su” can be removed, it is too basic; there may be
thousands of scripts and docs and procedures using it.
At worst, systemd would have to provide a compatibility layer: ie,
replace the “su” binary with another one that interfaces with systemd.
This is also a classic Linux technique: for instance, postfix contains a
tiny sendmail binary, in order to replace the sendmail veteran. If they
did not, it would have probably never have been adopted.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
I link this phrase. I was once arguing with the administration of a public library. They were sending bailiff threats for my unpaid membership as I was in too much chaos or trouble in my personal life to be dealing with insignificant things like paying my subscription, furthermore I wanted to take the chance to also send them some message about it as their prices were just way too high. It appeared after a while that there were other types of memberships (cheaper) but I had never seen it and they apparently do not or did not advertise it and the information was hard to find (almost on purpose). Because my payment was a chance to send such a message, but I had no time writing it, I postponed it slightly. As these businesses repetedly (perpetually and repeatedly) just automatically start sending collection bailiff theats without ever informing as to why a certain bill is not being paid, I sent an angry letter saying that they were forcing me to cancel my subscription. With this letter I also sent the ‘check’ I had for paying the membership for the preceding, last year. Then, against my will, I don’t remember how it came about, they no longer wanted me to pay the money anymore but as a gift were willing to give me a brand new, cheaper membershp (for pay).
That is not what I wanted. This changed my membership term amongst other things – also I believe the payment was in advance, not behind the fact. I just wanted at this point for that same old membership to run out and then I’d see, at this point I didn’t want a new one starting much later and ending much later. But the guy without asking deleted my old membership with no way to return it (for him) and created the new one, saying that they would send me a new bill.
He then said “You want this, because it is good for us and it is good for you.”
I said “I think perhaps I should be the one to determine what is good for me, not you.” I don’t think I have had a membership since, nor was I able to make any use of it were I to would have had one. So it ended in a good way with that goes perhaps.
But his feature was my bug…
I think it is a nice way of stating that common theme in human interaction using those programming terms. I encounter features that are my bugs on a constant, continuing basis.
Much of systemd is this way. Well, you’ve heard the rants perhaps. (I haven’t).
I find that I lose power to some other agent that is not my own with these changes. I become disempowered through them and the power transfers to someone else who can make these decisions. I always thought if you wanted to build something great, you could start with Linux. I no longer think that.
Correct.
xdg-su uses it e.g. as fallback on desktops other than KDE and GNOME, and even KDE’s kdesu uses it by default to gain root privileges (can be configured to use sudo instead though).
Regarding systemd’s su replacement: it probably uses polkit I suppose, which is a “proven” framework and used by many other parts of the system (the mentioned PackageKit e.g., and systemd already for things like shutdown/reboot/hibernate) to verify whether an action is allowed.
Polkit allows you/the system administrator or the distribution to configure who is allowed to do some action and which password is required (root’s or the user’s) if any.
You can always use aliases. 
And systemd has command line completion, for bash at least.
But as mentioned, nobody is going to take away su anyway.
init S or whatever doesn’t work anymore.
“init 1” should work fine, or adding ‘S’, ‘s’, ‘1’, or ‘single’ to the kernel boot options.
See “man systemd”:
single, s, S, 1
Boot into rescue mode. This is equivalent to
systemd.unit=rescue.target and provided for compatibility reasons
and to be easier to type.
These guys (I wanted to call them kerels in Dutch because they are clearly not women) just want to drag anything and everything into their own cozy little world where they can claim dominance and reputation share. They just want to own you. It’s that simple. They are power hungry.
Let’s call it a hostile corporate takeover.
I regard that as nonsense.
systemd is running as root already (it has to), so why would they need to add an su replacement for that?
Yes, but IMHO the defaults are wrong. The default behaviour of sudo on openSUSE is offering the same as su (which is why prefer su, two characters less to type ;)).
But as far as I know the default of Polkit isn’t that strict as su. Which means that the moment such a product is introduced there are new “features” that are experienced as security flaws by others (example the installation of “updates” by the end-user). But I guess I am now repeating myself.
As far as I can tell, the main concern is with inheritance.
When you use “su” the session inherits a lot from its parent shell. Apparently, the systemd people want to provide a version that opens a new shell that does not inherit.
I’ll wait and see how well it works.
su and sudo don’t offer exactly the same behaviour.
I suppose you mean that you have to enter the root password on openSUSE…
But both are unrelated to polkit (which I was talking about in your quote).
But as far as I know the default of Polkit isn’t that strict as su.
There is no single “default” of polkit.
There are rules for different actions (who is allowed to do that, and which password does s/he have to enter) that are configured in /etc/polkit*.
The defaults are defined by (open)SUSE’s security team, there is an “easy”/“standard” (allows a user to install updates without password e.g.) and a “secure”/“restrictive” set (which one is used is configured in /etc/sysconfig/security), local overrides by the administrator are possible.
I have not had a look at that systemd “replacement” yet though, and don’t know whether it does use polkit or not and what the defaults are if it does.
As hendersj wrote already, I see no reason to believe that this would be less secure than su though.
Sorry, I seem unable to get my message through. None of the remarks above is taking in account what I am trying to convene. Though they are true technicaly, but only very remote related to my message.
On 2015-09-01 14:06, nrickert wrote:
>
> As far as I can tell, the main concern is with inheritance.
>
> When you use “su” the session inherits a lot from its parent shell.
> Apparently, the systemd people want to provide a version that opens a
> new shell that does not inherit.
“su -” does not inherit.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
On 2015-09-01 14:36, wolfi323 wrote:
> As hendersj wrote already, I see no reason to believe that this would be
> less secure than su though.
The only issue I see (so far) is that it is untested, as any new thing.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Actually, it does.
Yes, it gets a clean environment, so it doesn’t inherit that. But it inherits open file descriptors, kernel keyrings, etc.
The concern, apparently, is that this is a potential security issue.
However,
ssh root@localhost
starts a new shell without inheritance. The new shell inherits from “sshd”, but not from the calling “ssh” process. So there are already ways of starting a root shell without inheritance issues.
As it is, we (at least I) have not the slightest idea what it is and which lack of feature it tries to address.
I tried to address the general fear expressed by the OP about something new that “becomes root”. I tried to explain that there are more of those he never questioned. I tried to explain that one should understand what “becoming root” is. Not magic as many Linux users assume, but a well defined and rather simple Unix/Linux mechanism based on ownership of files and processes and file permissions. And that tools using those mechanisms can be programmed with or without security holes. And that it is the job of every single system manager to assess the security vs. usability case of every one of them for their environment.
I also addressed the (Open Source inherent?) way things, that are less secure then before, are included in newer versions without a big sign telling so. Of course you often can reverse that (see the Packagekit/Polkit case), but without a warning it may take a long time before the system manager finds out that he has to do something, let alone find out where to do what to stop the gap.
That is all I tried.
I replied to your last post about wrong and less strict defaults, not to your first ones.
To address (some of) your concerns:
- Users should not be able to install updates or do other system related stuff
Well, there’s always a compromise between convenience and security. openSUSE’s defaults are more geared towards convenient desktop usage, but there’s a “secure” setting as well as indicated (in /etc/sysconfig/security, also configurable in YaST->System->Security Center and Hardening). This setting does not only apply to polkit though, but also determines whether those programs you mentioned are actually installed as suid root (there is a “paranoid” settings too that removes all suid root bits, thus even disabling su and sudo).
Regarding updates one could argue (and that is the security team’s stance AFAIK) that it’s more insecure to not install them, so it should be easy to install them for “normal” desktop users.
I very much doubt that “machinectl shell” would not need a (root) password though.
- suid root binaries are “dangerous”
If something uses polkit, it doesn’t have to be suid root anyway nor do user applications have to be run as root to be able to do system stuff. See PackageKit, NetworkManager, or systemctl, localectl and other systemd binaries.
Actually I’d say that is more secure than having to run the whole program as root (possibly via sudo), or even login as root.
On 2015-09-01 15:26, nrickert wrote:
>
> robin_listas;2726537 Wrote:
>> “su -” does not inherit.
>
> Actually, it does.
>
> Yes, it gets a clean environment, so it doesn’t inherit that. But it
> inherits open file descriptors, kernel keyrings, etc.
>
> The concern, apparently, is that this is a potential security issue.
I see.
>
> However,
> Code:
> --------------------
> ssh root@localhost
> --------------------
> starts a new shell without inheritance.
Well, it has to act as a total new login.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))