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.

Andy Lester
  • 339
  • 2
  • 6
Bananach
  • 477
  • 1
  • 4
  • 5
  • 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 '18 at 09: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 '18 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 '18 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 '18 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 '18 at 18:37
  • 2
    It depends on your role and the possible needs. As a developer I always had root access as I would need it multiple times a day – PlasmaHH Oct 25 '18 at 18:40
  • 2
    @Bergi Why are they storing important files on a WS of a lowly employee? If the employee needs them for their work it *also* needs access to them, if not why are they even there? Having root access or not should be completely irrelevant. AFAIK not giving root access probably avoids some people "breaking" their systems when trying to install/upgrade something, at the cost of having to deal with every type of installation/upgrade. For a developer machine which should only contain code&compilers &cuda etc I don't see the benefit of not giving root. – Bakuriu Oct 25 '18 at 20:09
  • I'm a software developer and I have root access to my machine, and to certain servers where I have a particular reason for it, but not to any other machines. Though there is not a strong focus on security here. – user253751 Oct 25 '18 at 21:28
  • What role does the employee have? Are you asking why *all* employees aren't given root access? – BruceWayne Oct 26 '18 at 15:48
  • I've seen both, larger organizations tend to not allow root without getting permission first while most medium to small organizations don't care enough to restrict that. – Mark Rogers Oct 26 '18 at 22:48
  • This is highly unusual. – John Keates Oct 27 '18 at 01:50

8 Answers8

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 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 '18 at 00: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 '18 at 08: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 '18 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 '18 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 '18 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).

me_and
  • 427
  • 3
  • 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 '18 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 '18 at 00:24
  • 1
    @BenMillwood - That's not possible if the admin configures a software restriction policy – paj28 Oct 26 '18 at 08: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 '18 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 '18 at 17:31
  • Yes, to be clear I'm not trying to claim these are all *good* arguments for the thing merely that they're arguments that might be used to justify the policy. – me_and Oct 27 '18 at 19:36
  • @EthanKaminski - Yes they do have similar things, both commercial products and bespoke scripting. With a tight config you can't run your own scripts. Is this something relevant to you, or are you just asking to be contrarian? – paj28 Oct 28 '18 at 21:48
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.

Jared Smith
  • 1,978
  • 1
  • 10
  • 12
  • 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 '18 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 '18 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.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • 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 '18 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.

Bob
  • 21
  • 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 '18 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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
user189852
  • 11
  • 1
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.

rackandboneman
  • 975
  • 4
  • 9
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.

user208145
  • 123
  • 3