35

Why do companies typically not give their employees root access to their desktop machines that are only used by a single employee?

If what I can do on my machine poses a threat to the rest of the network, isn't a security flaw in itself? Why would the rights I have on my own machine affect what I can do to others on the network?

Isn't the point of Unix user management to protect files of user A on machine X from access by user B on machine X?

If it's about protecting the user from himself (say, from installing something with root access that will wipe out the hard drive): Since I am working without root access, all my files are owned by myself; hence, if I am fooled and run an evil script without root access and it wipes all only the files owned by myself, it is just as bad as if I had given it root access and it wiped the entire hard drive.

Improve this question
11
  • 3
    What do you mean by root access? Do you mean not providing the root password to be able to sudo, or do you mean not allowing users to log into root?
    – schroeder ♦
    Oct 25, 2018 at 9:21
  • 38
    What make you say that is typical? I have had root access on my local machine in every job I have had.
    – kasperd
    Oct 25, 2018 at 15:01
  • 5
    This question would be a lot easier to answer if you had a use case for why you think you should have it.
    – Joshua
    Oct 25, 2018 at 15:49
  • 3
    Are you asking about *NIX systems in particular, or all work PCs (e.g., admin rights on a Windows machine)?
    – Jon of All Trades
    Oct 25, 2018 at 18:06
  • 2
    I don't think they couldn't protect the network from your machine. But what they ultimately want is to protect the company files on your machine from evil things (which might include you).
    – Bergi
    Oct 25, 2018 at 18:37

8 Answers 8

Reset to default
56

Security administrators are responsible for your machine and what happens on your machine. This responsibility violates the basic security model for a single-user Unix machine because the admin (an absent party) is root on your machine, you are not. Unix isn't really set up for this model.

Admins need to be able to install security controls on your machine in order to protect the company, not just the data and the network and the other nodes. If the local user had root access then admins are no longer in control over those controls. That's the basic premise.

Yes, there are tons of reasons why root is needed to do bad things or to turn the machine into a malicious node and all those are good reasons not to provide root access. And yes, there are lots of ways around those limitations and lots of ways that the local user could do bad things. But ultimately, the local user and the Risk Owner cannot be competing for control or responsibility over the machine.

Improve this answer
5
  • 10
    The first paragraph confuses me. Unix OSes are multi-user, not single-user, and that's precisely why they're set up for this model. That today most machines are intended for a single user, only results in not having multiple normal users, each with their own home directory, in a single machine. That's the only difference, right? The basic security model has remained multi-user, with root always being there for a possible separate administrator.
    – JoL
    Oct 26, 2018 at 0:10
  • 1
    The machine in question has only a single user (the OP). Of course Unix is multi-user, and that's the model that is being violated, because on a single-user machine, that user needs some admin rights.
    – schroeder ♦
    Oct 26, 2018 at 8:19
  • 5
    @schroeder just because nobody else sits at the desk and types doesn't mean there are no other users of the machine. If it's a work environment, the machine needs to be managed by an administrator, therefore it is NOT a single-user machine.
    – barbecue
    Oct 26, 2018 at 14:41
  • 2
    @schroeder I upvoted your answer, we're not disagreeing. I just think it would be good to point out to the user that just because he doesn't see another person using the computer doesn't mean there isn't another user.
    – barbecue
    Oct 26, 2018 at 14:46
  • 1
    I'd add that some IT departments do give sudo or root access to some of their users. The primary criteria for that seems to be that they'll trust users who (a) have an actual need for the facility (b) can be trusted not to abuse the facility, (c) are honest about what they did if they make mistakes and (d) know their limits and will not try to do things that they don't understand. The combination of those criteria rules out a great many people. Obviously, this kind of trust can't be awarded by management or HR, only by IT to people who they know.
    – John Dallman
    Oct 27, 2018 at 15:38
25

A few reasons off the top of my head:

  • ARP poisoning or network flooding attacks on the network would generally require root access to a machine on the network.

  • Being able to install unauthorised programs might open the company up to legal liability if those programs are themselves illegal (e.g. because they're pirated or not licensed for for-profit use or whatever).

  • If the company has any sort of remote monitoring of employees (or wants the ability to have such monitoring even if it's not in place yet), giving users root access would allow them to bypass that.

  • Not having root access means you can't rm -rf /bin, or any number of other destructive things, and nor can anyone who gains access to your login details, so there's no chance your company will need to help you recover from that situation.

  • If your company might redeploy your machine if you leave, they might feel more comfortable doing so without doing a complete wipe-and-reinstall if you've never had root access to it.

  • Giving people root access is easy, if it becomes necessary; taking root access away comprehensively is difficult if it becomes necessary.

  • The general principle of least privilege is that you shouldn't give anyone/anything access they don't actively need.

  • Simply not having moved on from the days of shared servers because it's a process that's worked and nothing has broken the inertia (the hypothetical monkeys and ladders problem).

Improve this answer
7
  • 7
    The second point isn't super strong because it's definitely possible to violate licensing laws with software you run out of your home directory.
    – Ben Millwood
    Oct 25, 2018 at 18:53
  • It is usually standard practice for a computer to be wiped and re-imaged when re-deployed to another staff member. Leaving all a previous staff member's stuff in their home directory seems like it may be more of a liability. I think of these points, the principle of least privilege is the most convincing reason for doing this, but that principle also justifies giving them root access as soon as they have a legitimate need for it.
    – thomasrutter
    Oct 26, 2018 at 0:24
  • 1
    @BenMillwood - That's not possible if the admin configures a software restriction policy
    – paj28
    Oct 26, 2018 at 8:53
  • 1
    Your first point is a bit off base. It's trivially easy to ruin a LAN from userspace, you don't even need intent, let alone elevated privilege. Hell, you don't even need a computer, you can walk into most office buildings with 15 feet or less of cat5 and ruin someones day by connecting the wrong two ports. There is a category of directed, malicious attacks that root access can enable, but it enables very few bumbling idiot mistakes that aren't trivially replicated from userspace all the time.
    – Iron Gremlin
    Oct 26, 2018 at 18:38
  • 1
    @paj28 Do Unix-style systems even have a "software restriction policy", and would that be of any use on such a system? (i.e., systems where you can "run scripts" and where the admin is named "root", as the question is asking about)
    – Soron
    Oct 27, 2018 at 17:31
12

This answer is not meant to contradict the existing answers, but rather supplement them because it's too long for a comment.

Part of the reason is (as others have alluded to) that users can't be trusted not to do foolish/malicious things. But another part is whose responsibility is it to fix things when that happens?

I'm a full-stack developer and part time devops with root access not only to my own development machines but a number of our production servers and at least some level of access to the hypervisor they're deployed on. But if I mess up, I am the party (or at least a party) with the skills, expertise, and responsibility to fix it. Not so of the typical end user: if Bobby the user borks his/her Windows install that happened to have mission-critical data and/or be used for mission critical work then Bobby isn't the one who has to come in on his/her day off or work unpaid overtime to fix it. Not to mention answer to the brass how Bobby managed to almost single-handedly sink the ship.

So part of the reason IT departments limit end user privileges is that it reduces their own risk exposure.

Improve this answer
2
  • 4
    How could Bobby have non recoverable mission critical data on his machine? How could I be more than a matter of half an hour to resetup his machine? Both seem to me like flaws in design. Also, as stated in my question, not giving him root acces doesn't prevent him from deleting the data he actually works on
    – Bananach
    Oct 25, 2018 at 20:45
  • 6
    @Bananach I never said unrecoverable, and I never said reimaging was difficult, but whose job is it to recover the data and redeploy the machine? Not Bobby's...
    – Jared Smith
    Oct 25, 2018 at 21:38
4

AFAIK, there are 4 main reasons not to give administrator access to standard users on their desktops:

  • protect the machine itself (not always very efficient) and the other machines on the network from possible attacks using that machine as a relay (already covered by other answers)
  • protect the IT support team from admin level attacks that will require a lot of work to fix (already covered by other answers)
  • keep all the machines with (more or less) the same config to be able to do simply remote deployments from one single admin machine - the smallest size the support team, the less expensive for the company
  • prevent (or at least try to) users to install programs unrelated to their job - a user playing games at work, or designing its future kitchen is not very productive...

But it cannot protect the data on the machine nor more generally the data accessible to the user, be on on the local machine or on a server. That is where backups come to the rescue.

Improve this answer
1
  • 5
    I'd emphasize the maintenance aspect. If the IT knows what's on each machine they have a much easier time figuring out what's wrong, or with updates. I have known IT departments who said "you can have root but then you don't have support". (I took root ;-). )
    – Peter - Reinstate Monica
    Oct 26, 2018 at 10:58
2

Your machine isn't only used by you. It's also used by your desktop support team.

If I have root access to a box - especially a domain joined Windows box - I can install any number of different tricks that I could use to compromise any other user of the box. Say, for example, a keylogger.

Then all I need to do is persuade a support engineer to log in to fix a freshly manufactured "problem" (such as breaking the kerberos shared secret), wait for them to elevate to domain admin and I've just compromised the whole network.

Won't the keylogger be detected by the malware scanner? Not if I have root it won't.

You get what you need to do your job. If your job needs root access, you get it - along with the associated power/responsibility talk. My job is to protect everyone else from you.

If you truly want root on your personal workstation, consider BYOD - but if you break it, you fix it.

Improve this answer
1
  • 1
    While this reflects working practices in many networks, it misses several attack vectors. When the threat model includes malicious users, I would never enter root credentials on an end-user machine, only machines stored in controlled environments (i.e. locked machine rooms). If the end-user has physical access to the machine, they can bypass the OS-level authorization protections, hardware attack vectors are trivial to deploy, and root's password hash hitting local caches is problematic. The exception is a machine-specific root password not shared by any other machine.
    – Cosmic Ossifrage
    Oct 27, 2018 at 17:09
1

The company has to protect things. They need to protect their trade secret, but they also need to protect things like user data. If every employee has another possibly insecure setup on his desktop, the company has no chance to make sure there is no data theft and no data loss. A centralized management by professionals helps to keep the computers secure and avoid accidental data loss.

Improve this answer
0

In case of a unix box connected to any kind of old school (v2 or v3) NFS file servers, local root access effectively allows a user to interfere with other user's files, since authorisation is partially implemented client side with these protocols, while authentication is under local user control this way. Meaning someone can just su to an existing or crafted user account with the same uid and have access to files belonging to that uid on NFS.

Also, is "only used by a single employee" the definitive or the usual way of working there? If machines are part of a common authentication domain, occasionally swapped between users as needed, or access to colleague's machines (but not their data!) is occasionally allowed, this looks like a pure single user scenario but it actually uses multiuser features for equipment management purposes.

Improve this answer
0

From a software license POV, I don't want users being able to install software willy-nilly. For example, a user wants to install Sublime Text, a text editor that allows one to use it for free for a limited time. S/he removes and reinstalls it after the allotted time. This would violate the EULA.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .