Major security flaw discovered in Linux sudo command

[RonSwanson]

They're even worse... Can't decide if they're ops or security or dev... Indecisive twits..

True, the problem though is that it's a reality today. In the 70s, 80s and 90s we could simply say

!devs in production

ISO/IEC27001 affirmed it with A.12.1.4

Today this wisdom is being challenged in a big way, and security peeps have to #livewithit

 

[Sinbad]

ISO/IEC27001 affirmed it with A.12.1.4

Today this wisdom is being challenged in a big way, and security peeps have to #livewithit

fkn millenials.

We don't have to live with their entitled attitude. There's no good reason to give devs access to production. All the ****en bugs are their fault to start with.
UNLESS
You make the devs perform 24x7 production support for a week after each release. Then they'll start coding properly.

 

[Swa]

Nonsense.

Firstly, not all users have physical access to a machine. 2ndly, hard drives can be encrypted, rendering the USB boot useless.

Privilege separation on a multi user systems exists precisely because there is a need to give differing users non-administrative access to a machine. They should not be able to elevate their privileges.

You've obviously never worked in IT in any position of responsibility.

Who said physical access is a requirement? Any access given to a user is a gaping hole as it's only one step further to more access. But with physical access I can do pretty much anything I wanted to.

Encryption? If set up correctly it does not matter and you need the decryption key regardless. If you're talking the typical "encryption" found on Windows machines the key is stored on the device in any case meaning I'll have access to it. If it's simply a password with no encryption it does not matter as I'll simply ignore the requirement. Point is if your system is already secure then this won't make it unsecure and if it's not already secure then the status of this is irrelevant. It's therefor not a security flaw.

Don't be so quick about judging someone's competence.

I have limited experience in secure shell on linux. I'm asking if it restricts you running ID specific when running a shared shell server?

It's stuff like the above that makes me not trust running crucial infrastructure on open source software. A few years back I wanted to dabble with samba server as a AD replacement and this just indicates it's a bad idea.

This has been majorly blown out of proportion. Windows systems are even less secure not even using hardware rights restrictions. Any program can change its own privilege level with a few workarounds. The nature of closed source means that we don't even know how many back doors MS is hiding.

 

[Sinbad]

Who said physical access is a requirement?

You did. You can't do anything with a USB stick unless you can plug it in

Any access given to a user is a gaping hole as it's only one step further to more access. But with physical access I can do pretty much anything I wanted to.

Again you refer to physical access.
There are genuine cases for user shell access to servers. You cannot avoid it in most IT organisations.

Don't be so quick about judging someone's competence.

Haven't seen evidence to change my opinion yet.

 

[RonSwanson]

fkn millenials.

We don't have to live with their entitled attitude. There's no good reason to give devs access to production. All the ****en bugs are their fault to start with.
UNLESS
You make the devs perform 24x7 production support for a week after each release. Then they'll start coding properly.

 

[Sinbad]

I didn't have BOFH GP as my PRN for nothing dude

 

[Gnome]

fkn millenials.

Dude how old are you, you are probably a millennial, you do realize this right?

We don't have to live with their entitled attitude. There's no good reason to give devs access to production. All the ****en bugs are their fault to start with.
UNLESS
You make the devs perform 24x7 production support for a week after each release. Then they'll start coding properly.

In my company if you build it you own it.
From coding, to testing (there are no "testers" in my company, automated testing or GTFO), to rolling it out world wide.

The results speak for themselves, people don't want to put sh#tty code in production because they'll get paged all hours.
On-call rotates so it isn't 24/7/365, more like 24/7 for one week every 2 months.
But still a strong deterrent for the kind of behavior that goes around in a lot of companies

There are genuine cases for user shell access to servers

To sort of mirror what you are saying, from my own experience:

Windows servers are exceedingly rare for most infrastructure (ie> things you'd put in the cloud, servers, web-sites, etc.)
And Posix servers without remote shell access is not something I've seen before (although I can see it being possible)

If this works in a remote shell, I'm going to go ahead and say this is one of the biggest exploits out in the wild right now.

 

[Swa]

You did. You can't do anything with a USB stick unless you can plug it in

Again you refer to physical access.
There are genuine cases for user shell access to servers. You cannot avoid it in most IT organisations.


Haven't seen evidence to change my opinion yet.

I'm referring to both, which you don't seem to get.