How can I set up a password for the 'rm' command?

My friends keep deleting my files using the terminal. So please help me out by explaining how to make a password for rm command.

Solution 1:

There's no easy way to set up such a password on the rm command itself, not without a lot of code hacking that'll probably break things like apt-get installing packages and removing files, and making you have to enter the password a thousand times, or potentially disrupting access to the command to people who would need it (like you, to delete your own files). You can sort of do this by having multiple user accounts and multiple access permission sets, and restricting access to different sections of data, such as your home directory so they can't get to it.

(The other option is individual user accounts for each users, and then Access Control Lists, as is detailed in the other answer that was posted by Videonauth)

Here's the core problem - you're letting your friends use your system. This has numerous security implications - the concept of "anyone with physical access to the box is going to be able to control the system and do any tasks" is an IT Security Mantra, which is why you don't 'share' physical systems access except with trusted authorized personnel.

The only truly sane way to do this is to not give your friends access to your computer, and give them a 'dedicated "Guest" system' that they can use, that you don't really care about the files on as much. This is the most 'secure' way to keep your files safe.

Of course, if that's not an option, then your only really safe option is to configure multiple user accounts, one for each user, with different home folders, and do not allow them access to your own home directory or access to any other user's home directories. And then keep everything you don't want them touching in your home directory, and don't give them sudo access, the root password, or share your password with them.

This is how you'd do this:

Let's say my name is "Foo" and I want user "Bar", a friend, to use my system but not access my files. The first step is to deny access to anyone but me to my home directory. This is to permit other users to not delete your files, but to also prevent other users from snooping around in your home directory and seeing what types of stuff you've got in your home directory:

chmod 750 /home/Foo

The second step is to create a user account for "Bar" (do NOT type what's in parentheses below, it's for information purposes only). This way, we can make sure he has his own separate set of access rights:

sudo adduser --create-home --user-group --shell /bin/bash Bar
sudo passwd Bar
(set a temporary password - you will not see characters as you type though)

The third step is to then restrict their home directory too so nobody can pry into their files either. This is just making things equal.

sudo chmod 750 /home/Bar

Wash your hands, rinse them off well, then repeat these steps for however many users you have on the system. They won't be able to access your files, and since you're not going to give them administrator privileges, they can't delete your files without attempting to sudo to do so - since you don't permit this, they can't touch your stuff. And they won't be able to see your files either, without becoming superuser, which won't happen here.

ALWAYS REMEMBER THIS: By giving someone physical access to the machine, or access in general, you are going to put your files and data at risk. This is a widely-accepted fact in the IT Security world, and one that continues to hold true. Giving your friends access to your computer will always put your data at risk, so either give them their own system to mess around with, or just don't give them access to your machine.

Just a note on disk encryption

While disk encryption works well to protect your data from a third party, there's limitations.

1. If the system is on, the disk is already decrypted, so you're at risk.
2. Some systems have broken disk encryption approaches. For example, some Acer systems use your password to only authorize the encryption/decryption and use hard-coded passwords, or use weak encryption that is easily cracked.
3. There are always methods to break into the 'keys', or try to extract them from memory just after a system is turned off but before the RAM data is 'gone' or deteriorated. (I will not go in depth on these, but these risks do exist).
4. Physical access to the machine, whether the system is encrypted or not, will always put your data at risk. Don't give physical access (or remote network access) to people you don't want to potentially give full access to your system to.

While Disk Encryption doesn't solve these problems, it puts extra layers of headaches for a threat actor. Someone who is a bad guy might give up if it's encrypted, or they may torture you (queue obligatory XKCD Security comic strip).

Therefore, if your system is encrypted, but you're letting other users use it, either they have a password to decrypt, or you're leaving your laptop decrypted so they can SSH in or have physical access. In both these cases, it's bad.

That said, if your system is not encrypted, then this section has no relevance for you.

Solution 2:

This may not really be about the rm command, since there are easy ways to delete files without using it. If the problem is that your friends are unintentionally misusing the rm command, then solutions that restrict use of that command specifically or cause it to work in a different way may be of some help. In contrast, if the problem is that your friends are deliberately treating your data in a way you don't want, then you need to implement actual security measures, and no solution that focuses on the rm command itself (or any discrete set of commands) will keep you safe.

Do you need to control access, or just prevent honest mistakes?

Assuming your friends know you don't want them to delete your files, there are two possibilities:

1. They could be doing it on purpose. In this scenario, your friends are deliberately deleting your files, and you cannot even trust them to try to comply with your wishes about how they treat your data when they use your computer. The only solution to this problem is to use an actual effective security measure, as Thomas Ward has explained in detail. Often the best such measure is to keep them from using your computer. But making them use their own user accounts can provide some protection.

2. They could be doing it by mistake. In this scenario, your friends are extremely accident-prone, and they keep running rm commands they wish they hadn't. They want to treat you and your data with respect, but are really bad at doing so in practice because they keep running the wrong command, deleting the wrong file... or something like that. Although it would be nice to believe that this is what's happening, I caution you against assuming that people who keep deleting your data after you've told them to stop are operating without ill will.

   Furthermore, even if their intentions are good, giving them separate user accounts is still the most foolproof way of preventing them from deleting your files, aside from not allowing them to use your computer.

If the situation really is #2 -- your friends are not trying to delete your files but just need help not accidentally deleting them, and the only way they ever accidentally delete them is through the inadvertent misuse of a small number of commands (like rm) that they have particular trouble using correctly -- then the techniques in Videonauth's answer may be of some use. But you must understand that they are not security measures, because the rm command is just one of many easy ways to delete files. See below for details.

I recommend you ask yourself, "Is my situation basically the same as if I, rather than the other people who use my computer, were the one using rm incorrectly?"

If the answer is no, then this is a matter of information security, and you need prevent your friends from using your user account. If the answer is yes, then you can use the same approaches you'd use if you were the one misusing rm:

• Education. Your friends need to know what they're doing and how to avoid it.
• Interface changes. Without taking away the actual ability to delete files (which requires separate user accounts), you can make it harder to accidentally delete files by making it so just running rm file by itself, without any further action, won't immediately delete file. Videonauth's answer gives one approach to this. In this answer, I present another.

But even if your friends aren't trying to do anything wrong, you should still consider having them use their own separate user accounts. This will still solve the problem -- the same security measures that protect data from deliberate destruction will protect it from unintentional destruction, too. Even without malicious intent, if someone keeps doing something you don't want them to do, then you cannot trust them to refrain from doing that thing.

Making rm prompt before deletion can help prevent some mistakes.

To help people avoid accidentally deleting files with rm, you can make rm a shell alias that actually runs rm -i. Passing the -i flag to rm causes it to prompt the user before deleting each file (see man rm).

You could do this (for your user account) by adding alias rm='rm -i' to your .bash_aliases or .bashrc file. See this question and that one for details. This will take effect for your newly opened bash shells.

This provides no actual security, and is not foolproof at preventing mistakes either, because:

• They can choose to go ahead with the deletion, when prompted.
• They can bypass the alias in numerous ways, including by running /bin/rm or unaliasing it (unalias rm).
• There are many situations where alias expansion does not occur, and in these situations rm will not be run with -i.
• They can still delete files by using any of the techniques to do so that do not require rm (as is the case with Videonauth's approach -- see below).
• They can still damage data without deleting any files, such as by overwriting them or otherwise changing their contents (as is also the case with Videonauth's approach).

But if you don't need actual security (see above), then this might be the way to go. By comparison to the approach of preventing your friends from using the system-provided rm command:

• Aliasing rm to rm -i is less effective at preventing mistakes -- until they move on to using some other technique to remove files. At that point, keeping them from using rm will be entirely ineffective, even if they're not trying to do anything wrong, since presumably they'll use unlink (or any of the countless other commands that remove a file) with equal thoughtlessness.

• On the other hand, because alias expansion only occurs in some situations -- roughly speaking, ordinary interactive use of the shell -- your friends might think they're going to be prompted when they're not really prompted (because the command is in a script, for instance, or issued from a different shell). Videonauth's way does not have this problem, which is an objective advantage of that method over alias rm='rm -i'.

• When a script runs, unless it is written deliberately to use aliases, your aliases are not expanded in it. This means that aliasing rm to rm -i is very unlikely to break anything. This is an objective advantage of alias rm='rm -i'.

rm can't do anything any other perfectly ordinary program couldn't do.

There's really nothing special about rm. It is a convenient and self-documenting way to remove files, so restricting access to it risks breaking numerous scripts that rely on it. But it is far from the only way to delete files -- it's just an ordinary program.

A few commands perform some task that a limited (non-root) user cannot perform without running them. For example, sudo lets you run programs as another user, after checking to ensure you're allowed to do so. passwd edits the database where users' passwords are stored, but only lets you change your own password (unless you're root, in which case you can change anybody's password).

/usr/bin/sudo and /usr/bin/passwd can do that because they have the setuid bit set, as shown by the s that appears in the leftmost column when you run ls -l:

ek@Io:~$ type -a sudo passwd rm
sudo is /usr/bin/sudo
passwd is /usr/bin/passwd
rm is /bin/rm
ek@Io:~$ ls -l /usr/bin/sudo /usr/bin/passwd /bin/rm
-rwxr-xr-x 1 root root  60272 Feb 18  2016 /bin/rm
-rwsr-xr-x 1 root root  54256 Mar 29  2016 /usr/bin/passwd
-rwsr-xr-x 1 root root 136808 Aug 17 09:20 /usr/bin/sudo

Notice that /bin/rm has no s: its permissions are -rwxr-xr-x, while /usr/bin/passwd and /usr/bin/so have -rwsr-xr-x instead. This makes it so that, no matter who runs passwd or sudo, it actually runs as the root user, since root is the owner of the executable. (There is also a setgid bit, which, when set, causes executables to run with the group identity of their group owner rather than that of the caller.)

Except for any security vulnerabilities that haven't been discovered yet (or that have been discovered but haven't yet been patched), sudo and passwd are safe because those utilities are very carefully written so they can only do things that the caller ought to be allowed to do.

/bin/rm doesn't work this way. It's not setuid because it doesn't need to be. Directory permissions (and occasionally file permissions) control what files a user can delete, and they don't need to become root to do it. Just to be perfectly clear, please do not ever set the setuid bit on rm. The security implications would be disastrous, since then, no matter who runs rm, it's as though root ran it! (Utilities like sudo and passwd check who's really running them and check that something is permitted before doing it; rm does no such thing.)

Checking if the setuid (or setgid) bit is set on an executable will tell you if restricting who may run it stands a chance of improving security. Executables that aren't setuid (or setgid) don't have any special status, and anyone can simply copy them and run the copy, bring their own copy from another machine, write a script or program that does the same thing, or use another program to do it.

Deleting Files Without rm

The obvious way to delete a file without rm in Ubuntu is to navigate to its location in the graphical file browser (Nautilus, if you're using Unity or GNOME Shell) and delete the file. There are also numerous commands that can be used to delete a file from a terminal, without ever using rm.

For example, to remove a file called foo.txt in the current directory, the following commands, which work out-of-the-box on Ubuntu and do not require access to rm, will achieve that. (Just to be sure, I tested them on a 16.04 minimal system installed with only the standard system utilities, after deleting /bin/rm.)

• unlink foo.txt
• busybox rm foo.txt
• perl -e 'unlink("foo.txt")'
• python3 -c 'import os; os.remove("foo.txt")' (python instead of python3 in older releases)

That list is, of course, nowhere near complete. No complete list of such commands is possible. Preventing file deletion is one of the things separate user accounts and file and directory permissions exist to achieve. They work very well to prevent it. In contrast, changing the rm command (to make it require a password, or in any other way) or restricting access to rm don't prevent it at all.

Solution 3:

You can change the permissions on the /bin/rm command via the following line which will prevent it being executed without sudo access:

sudo chmod 750 /bin/rm

This specifically prevents them from using the rm command provided by the system. You should be aware that it does not prevent them from deleting files in other ways.

To also prevent them from using the rmdir command, which is a common way to delete directories, you can set permissions the same way on its executable path:

sudo chmod 750 /bin/rmdir

Remind that as well you can only use this commands with sudo rights too.

To change it back if you not like it or other problems occur use 755 for chmod

As @muru pointed out the above is a very crude solution and might even break system services which are not running on the root account. Therefore I add here another option using ACL (access control lists) to do the same and probably much safer (good to read into as well and you can skip the enabling part because ACL is usually installed on Ubuntu systems nowadays):

So to do the same as above just for the users you want to block would be

sudo setfacl -m u:<user-name>:- /bin/rm /bin/rmdir

Just replace <user-name> with the actual user names you want to prevent using the files.

As with chmod, using setfacl -m to prevent specific users from running rm and rmdir applies to those system-provided commands only. It doesn't keep them from deleting your files and folders in Nautilus or by using other terminal commands.

Explanation:

• the -m flag means to modify the files ACL.
• the first part of the change, the u stands for user. It can have the following values u for user, g for group and o for all others
• the middle part <user-name> can holt the actual user name or group name according to what you want to change. To set overall changes you leave it empty.
• the third part holds the kind of permissions you want to set. Here in the example we want to set no permissions at all so we put -, it can as well contain the following letters r for read permissions, w for write permissions and x for execution.