3

I want to lock my /etc/hosts file so that you need a password in order to write. I know you can encrypt files with Disk Utility, but in this case the file needs to be read by the computer and the path/extension cannot change. I don't just want to lock the contents, I want to lock this file very specifically.

If I run sudo vim /etc/hosts I need to type my login password but can then do whatever I want.

I want a solution where if I run sudo vim /etc/hosts, I must type a customized/specific password to write to the file.

| improve this question | |
  • From whom, or what, do you want to lock it? By default, the file can only be written to by users or processes with root access. – benwiggy May 6 '19 at 17:51
  • Lock it from anyone (including admin) who does not have a particular password – luca590 May 9 '19 at 18:31
  • 1
    I have the impression one could figure out a way to set up /etc/sudoers so it will block sudo vim and users would instead need to do a sudo -u hosteditor vim ... with a different password. See man sudoers. – bdecaf May 30 '19 at 9:04
  • 1
    I agree with @bdecaf - it will be playing with (and altering) the sudoers file. applegazette.com/mac/… points out that you must use a special editor, visudo, but I'm not sure if that is still the case. It used to be, and you could wreck your sudoers file if you just use nano or vim or whatever. – FiddleDeDee May 30 '19 at 15:20
  • 1
    @Ian the command is still called visudo - but you can set EDITOR or VISUAL to your preferred editor. This will then be used. Btw. this also works with sudo -e which is more comfortable as it will also use the users editor setup (and not roots). – bdecaf May 31 '19 at 2:11
4
+50

The /etc/hosts needs to be readable by other program in order to fulfill its purpose. If you encrypt the file in any way, those other programs will not be able to read the file - and it will stop working.

So in short, you cannot do this (i.e. encryption) in a meaningful manner.

However what you can do is ensure that others do not have passwords for administrative accounts on your Mac. If they do need more privileges for something, make it so that you assign access to that specific resource (for example via a sudo access limited to a specific program) - and ensure that you do not give out full administrative access.

An example of using sudo for giving access to edit a file is to use the "sudoedit" option in sudo. This allows you to give another person access to edit a file without letting their editor run as the privileged user (which is bound to let them "escape" and allow them to other things as the privileged user). It is achieved by copying the privileged file into a separate location, letting the user run their usual editor under their own user id to edit that file, and then copying its contents over the privileged file afterwards.

In sudoers you would specificy something like:

username  sudoedit /etc/hosts

By default this will allow "username" to edit that file, and requires him to enter his own login password before doing so.

If you want to the user to input a different password, that is not his login password, you have basically two ways of going about it.

One way is not to use "sudoedit": Instead create a custom program (can be a shell script) that simply inputs a string and checks that it matches the password you want, and then just mimics what sudoedit does. It can also be quite simple and just a "cp" command to copy over a specific path from the user's own home folder to /etc/hosts.

The alternative is to modify which passwords sudo will accept as valid. This is done by editing /etc/pam.d/sudo and uncommenting the standard lines beginning with "auth". Instead provide the authentication module and options you want to approve.

If you want to do something completely custom, you can compile your own PAM module that simply asks for a password and checks that it is a specific string. You can start with the source code for the default pam_opendirectory PAM module and simply rip out the OpenDirectory parts and replace it with a simple strcmp(). The source code for such a custom module is very few lines of code.

You can find the pam_opendirectory PAM module source code here:

https://opensource.apple.com/source/pam_modules/pam_modules-76/pam_opendirectory/pam_opendirectory.c.auto.html

| improve this answer | |
  • 1
    "I want a solution where … I must type a customized/specific password to write to the file." – Joel Reid May 30 '19 at 13:32
  • Hmm, you can change sudoers to select a custom password instead of the login password. – jksoegaard May 30 '19 at 14:55
  • So, I'm on the really on fence on whether to upvote or downvote your answer here, because you've kind of given both the worst and best answer: "in short, you cannot do this in a meaningful manner" is totally incorrect because it can be done "in a meaningful manner", by, as you say, ensuring "that you do not give out full administrative access" and making it so that you assign access to that specific resource (for example via a sudo access limited to a specific program)". ;) – Geoff Nixon Jun 2 '19 at 17:02
  • @jksoegaard A custom password? I think you can set it to ask for the root password, but custom? Do you mean, like, via a PAM plugin? PAM is so completely undocumented on Darwin, do you have any resources on how to reliably do this? – Geoff Nixon Jun 2 '19 at 17:09
  • @GeoffNixon I think you just misunderstood what I meant by "this" in the sentence. I'm referring to encryption which was suggested in the question. You cannot do "this" (i.e. encrypting the file) in a meaningful manner. It won't work. However, as I suggest, there are other ways of achieving what he wants - namely by restricting access and only assigning access to a specific resource, such as a fixed editor for that single file only. – jksoegaard Jun 2 '19 at 19:17
1

Ok, so here's a completely fresh answer that's not a "half-solution".

Whether this is what you actually are looking for, you can tell me.
But to reinforce the answers above:

  1. Change your default account to a non-administrator account.
  2. Create a new administrator account, with a unique password; this account will only every be used to edit /etc/hosts.
  3. Write a wrapper script/shell function to wrap/supersede sudo, also checking the arguments in $@ here to ensure /etc/hosts is the file in question.
  4. read the password for the unique admin user into a shell variable.
  5. Use the rest of the script to su to the admin user using that password, then then again to /usr/bin/sudo vi /etc/hosts.

You will then have a solution where when you "run sudo vim /etc/hosts, [you] must type a customized/specific password to write to the file."

| improve this answer | |
  • The problem with this solution is that it also allows the user to do other things as that specific admin user. – jksoegaard Jun 2 '19 at 19:37
  • I like this answer (upvoted), because technical it does solve the problem, but being restricted to a non-admin account and then having an outstanding admin account that can do anything makes it pretty impractical – luca590 Jun 6 '19 at 15:35
  • Yes, this answer was somewhat tongue-in-cheek. ;) – Geoff Nixon Jun 7 '19 at 17:55
0

Assuming your account is an administrator account, I think your best bet would be to Enable the Root User (with its own password, and remove the admin group from the sudoers file.

  1. Open Directory Utility. There might be a way to do this from the Terminal, but open Directory Utility.app you can get to it via

    • System Preferences > Login Options > Network Account Server > Join...

    • open -a "Directory Utility"

    • etc... (it lives in /System/Library/CoreServices/Applications)

  2. Click the lock, then under the Edit Menu, select "Enable Root User".

  3. Set a unique password.

  4. Make sure this works. In your terminal, type su root, and enter your new root password. You should be able to edit your hosts file.

  5. In your terminal (as default user), type sudo visudo, (enter your password).

  6. Comment out the line:

%admin ALL = (ALL) ALL

to

## %admin ALL = (ALL) ALL

  1. Save the file.

Try this again. You should now get an error to the effect of:

  1. [User] is not in the sudoers file. This incident will be reported.

This is not exactly file-specific, but it seems like what you were going for?

(To restore, use su root, not a sudo-related function).

| improve this answer | |
  • @user3439894 You're right, I guess the hosts file isn't on the blacklist. Edited. Thanks. – Geoff Nixon Jun 2 '19 at 17:52
  • Read the answer again. I wasn't suggesting at all that is was necessary to edit the sudoers file. It is, however, 1. A way to have a "unique password" aside from the user's admin password, and 2. It is necessary if one is to remove sudoer privileges from the admin group, which is what I was suggesting to mitigate the risk of other admin users modifying the hosts file, as otherwise you'd be left with no way to escalate at all. As for those who consider it a security risk simply to enable it at all... well, I don't travel in those circles; and again I was not suggesting it needlessly. – Geoff Nixon Jun 2 '19 at 18:58
  • Sorry if I misread something however the real point I was trying to make is that your suggestion to "Enable the Root User" is IMO ill advised, unsafe and not at all necessary when there are safer alternatives. (As in the answer by jksoegaard.) – user3439894 Jun 2 '19 at 19:48
  • 1
    'Enabling the root user', however well intentioned, is not a great idea. It's disabled for a reason (to make the system harder to compromise) in many distros now. – FiddleDeDee Jun 3 '19 at 7:13

You must log in to answer this question.

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