An easier option ...
Climb up the outside of the building and hang upside down outside the SysAdmin's window using your smartphone to video them signing on.
Most video editors have a 180 degree transformation tool. HTH.
A dispute has arisen about the seriousness of a vulnerability in Linux, dubbed "Grinch", that supposedly creates a privilege escalation risk. The flaw resides in the Linux authorisation system, which can unintentionally allow privilege escalation, granting a user “root", or full administrative, access. “With full root access …
This post has been deleted by its author
It is bollocks.
A user given a higher level of trust might be able to abuse that trust, go figure.
As physical access is required (if the same user tries via SSH, they'll be prompted to enter a password) it's something of a non-issue given the huge amount of pain that could be brought by anyone who gains physical access.
Be careful who you give higher privileges too, and be very careful about who you allow physical access to. Not an awful lot of news there.....
The OS-Sec mailing list was particularly scathing of this 'vuln', but as a side effect, someone looking into this did discover a real privilege escalation vuln - CVE-2014-9322 - so something good has come of it at least
As physical access is required (if the same user tries via SSH, they'll be prompted to enter a password) it's something of a non-issue
Indeed. With physical access to a machine all an attacker needs do is stick in their own disc and poke the power button to gain root access on any system. It doesn't even matter what OS the system is running at that point.
Full-disk encryption with the passwords kept away from the hardware would slow someone down considerably in the task of accessing the installed system
Not really, no, unless the server happens to be powered down when the perp gains access to it. If the system is running whole-disk encryption is a minor inconvenience only if your strategy involves rebooting the system, which in most cases would be the best way to alert the rightful admins that something is up. If you keep the system running you're not event going to notice that the disk is encrypted...
but how common is that on a server?
I'd guess "not very", perhaps because a server is typically designed to stay up, while whole-disk encryption is only useful to prevent either disk theft or unauthorized boot.
Once you have physical access you can screw pretty much any system.
That's a terribly simplistic threat model. Of course, it's often a useful threat model, since the guidance it provides - increase physical security until the work factor for gaining physical access is greater than the estimated reward to an attacker - is straightforward and in many cases relatively easy and inexpensive to provide.
But where physical access has to be included in the threat model, there are a great many possible mitigation steps that increase the work factor for an attacker with such access. Just throwing up your hands and saying "game over" in such a situation would be lazy and unethical.
For one thing, "physical access" is not well-defined. If it's taken to mean "in the same room as the server" - a common insider threat - then the machine can still be physically secured to make removal harder, the case locked closed, ports sealed, etc. Surveillance can increase the counter-threat for the attacker and so the attack cost. Disk encryption, as Charles mentioned above, prunes some attack branches (or makes them far more expensive), such as stealing the disks or rebooting. TPMs and other tamper-resistant security modules can also make booting and other extraordinary actions more difficult.
Security is never an absolute condition, and anyone who treats a broad class of situations (such as physical access) as an absolute security situation should not be in charge of security. Any security evaluation should be justified by reference to a threat model.
This post has been deleted by its author
If you read the alertlogic page, it seems to be saying that anybody in group wheel can run sudo. Therefore, the wheel group user could potentially alter the configuration of polkit in a way that would give them full root rights.
I agree with Red Hat, it would seem to be expect behavior. Indeed, the default sudoers on RHEL 6.6 would allow anyone in group 'wheel' to become root just by typing sudo su -, a well known feature, and no messing with polkit.
@Jim 59 - you didn't miss anything. The vulnerability is limited to users that could already utilize it. With that said, if an application got fired off with that user's rights and then escalated, then we might have a problem. :) As always on servers (regardless of OS), if you are on the physical console (or virtual physical for vm's), you should have a good reason for doing so.
Net takeaway - be sensible in your assigning of sudo rights, and be sensible in how you access your servers. That is nothing new to seasoned sysadmins.
It is like saying "if you leave the keys in the ignition of your car, someone may drive it away without your permission."
sudo is a loaded gun for the amateur.
There is an EXCELLENT article from linux journal about configuring systems to run without root being needed for just about everything.
Ubuntu is for the playgroup crowd and comes with sudo for everything.
Again I say it, with COW a lot of problems go away.
Linux has snapper for admins too.
A round of of the news. Total bollocks article where configuration option is promoted as FUD.
The BASH one, however, was very , very clever....!
P.
I think polkit was developed much in the MS style (like systemd) so that users on the system don't need to *think* to be able to do anything, i.e. enabling normal users to do admin jobs (that they shouldn't be allowed to do anyway without a bit of knowledge).
It called the London Screwdriver.
I'm not certain, but anecdotally its main functions on my machine appear to be making user mounts an utter crap-shoot from one "upgrade" to the next, and ensuring that I have to enter my root password and wifi passphrase at least three times each whenever the signal hiccups.
I agree with Redhat's assessment. The wheel group is meant to be given only to users who are expected to have root access to the system. I.e.you give it to admins, not every user on the system. So, this particular package installer permits wheel-group users, if and only if they are logged into the physical console, to install packages without asking for a password. It's like being surprised that a Windows user who has been added to he Administrator group can perform Administrator activities; not particularly a surprise at all.