>An unprivileged user shouldn't be able to take down a production system

Why do these people have shell access to production systems in the first place?

My line of thinking was theft or data modification.

I have access to this box and it has granted me access to some other system which has useful data, like a database, NFS mount, or S3 bucket. Let me hop in here and grep for something juicy to steal, maybe flip some bits around to fuck with people, or just delete shit.

But an unprivileged user can't do any of that. The entire point of unix permissions is so you can't mess with other users' files unless you've explicitly been granted permission. File owned by, say, mysql are owned by a separate "mysql" user by default.

If there are readable configuration file sitting around, then it's totally possible to get the credential for other systems. I see this stuff all the time and have leveraged t his fact for troubleshooting systems that I'm unfamiliar with.

> theft

You can't steal data unless if you intentionally delete the original after copying, but then that is not really theft as any proper organisation will have backups.

You know what is meant. This kind of pedantry doesn't add to the conversation.

"Theft" is a nice easy word for making a copy of data that you do not have permission to access.

So someone steals a book from a library isn’t theft because they have secondary copies?

A better analogy would be photocopying all the contents of one of the books and putting it back on the shelf

DoS attack, ex: consuming CPU or RAM resources.

That’s a class of attacks that sudo doesn’t even pretend to address. I’m not championing sudo, but consider it as one piece of a “Defense in depth” approach.

I believe the commenter was more talking about giving shells to a daemon than any sudo shenanigans.

I reread, can see that now. I think the commentor was speaking to a conversation that had shifted. I’ll leave my comment but also vote them up - theirs was a fair point.

cgroups let you limit a user's usage of system resources. Like disk quotas, you need to configure this yourself if this is a threat model you care about, but it comes out-of-the-box with all modern distros.

> An unprivileged user shouldn't be able to take down a production system

How about deleting everything under /var/www/?

An unprivileged user can't do that. /var/www/ will be owned either by root, or (by default on debian, depends on your distro) www-data. Your unprivileged user can't modify other users' files, that's the entire point of unix permissions.

Given

> >Plus, there's still a lot of damage you can do without root access.

> That's not really true. An unprivileged user

We can see that "unprivileged user" equals to anything that is not root in your post. Considering that definition www-data is an unprivileged user which can delete everything under /var/www/.

So no, what you are saying is not really true.

But www-data doesn't get a login shell, so it can't[1].

Obviously a user can modify their own files. The idea is if you compromise unprivileged user "scott", with their account, you can't harm other users or the system itself.

[1]easily. Technically it depends, but a hardened configuration would only give www-data permissions to read files its data files in /var/www, not write them (which includes delete), apart from things it actually needs to write like its app logs (and even then you should be using syslog facilities, which only let you write, again not delete or cause any issues). Principal of least privilege and all that. For fun, try to figure out how to ssh into your system as www-data and see the half dozen different roadblocks that come up in your way.