How the Operating system prevents normal users from executing commands like fdisk and umount eventhough the commands have execute permissions for everyone ?
[root#r7prd1 ~]# ls -la $(which umount)
-rwsr-xr-x. 1 root root 31960 Aug 21 2015 /usr/bin/umount
[root#r7prd1 ~]# ls -la $(which fdisk)
-rwxr-xr-x. 1 root root 182472 Aug 21 2015 /usr/sbin/fdisk
There probably may be some situations when it may be worth to disallow user to execute any binaries (I suppose it may be one of countermeasures against privilege escalation exploits). But in many cases regular users are able to execute their own binaries, so what if user will write and compile fdisk or something similar by himself? Really, you don't want to disallow user to run fdisk. You just want to disallow fdisk or any other program to modify the system state in some way. So regular user really can execute fdisk:
$ fdisk --help
Usage:
fdisk [options] <disk> change partition table
fdisk [options] -l [<disk>] list partition table(s)
...
What regular user actually cannot do is executing restricted operations:
$ fdisk /dev/sda
Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
fdisk: cannot open /dev/sda: Permission denied
So fdisk started successfully, printed some messages. Then it tried to open raw disk device /dev/sda and it was that operation that was really restricted by permissions, so fdisk just complained that it cannot do anything and exited.
There are some cases, though, when you may want to restrict executability of some binaries by some users. When administrator or OS maintainer want regular user to be able to execute some privileged action (such as mounting some partition that this particular user is allowed to by some record in the /etc/fstab), them set up some special hardened binaries such as mount or sudo with set-user-ID permission:
$ ls -l /bin/mount /usr/bin/sudo
-rwsr-xr-x 1 root root 40152 May 27 02:31 /bin/mount
-rwsr-xr-x 1 root root 136808 Aug 17 16:20 /usr/bin/sudo
When such binary is executed, the kernel gives it not the user ID of the calling user, but, in this case, UID 0 (root). Because regular user cannot set binaries up this way (root owner and set-UID bit set), then it may be theoretically worth restricting executability of these binaries to some particular group (but in the above case, they are world-executable and check permissions of calling user by themselves. I don't really know, if executability restrictions of set-UID executables cannot be circumvented in some way and whether such as approach is really widely used by someone).
And one extra note: in case of fdisk on your system, it is installed to /usr/sbin directory that may or may not be in the PATH variable of regular users, so fdisk may or may not be executed by regular user by just typing fdisk at command prompt, but it is not really a restriction (one may simply specify full path to executable on the command line).
Related
I have a script written by someone else, which mounts a file system, and I would like to reproduce it.
The script has been compiled with shc, and is used to mount a filesystem for a particular user, but is able to be run with root priveleges. The guess is it does something like this mount_script.sh:
#!/bin/bash
mount -t cifs -o username=$USER,domain=my_domain //hostname.com/Files /mnt/${USER}-drive
I have compiled the script with shc and then applied
chmod u+s mount_script.sh.x
so that
-rwsr-xr-x. 1 root root 11088 Feb 15 14:11 mount_script.sh.x
matches the original compiled bash script's permissions, the original is wrapped with the following mount_drive.sh
#!/bin/bash
if [ "$(mountpoint -q /mnt/${USER}-drive/ && echo "mounted" || echo "not mounted")" = "not mounted" ]; then
echo
echo "Not mounted, running mount script..."
echo
mount_script.sh.x
else
echo
echo "The drive is already mounted at /mnt/${USER}-drive..."
echo
fi
WIth permissions:
-rwxr-xr-x 1 root root 335 Sep 20 10:58 /usr/local/bin/mount_drive.sh
When I try and run it as my normal user i get:
Not mounted, running mount script...
mount: only root can use "--options" option
What should the script contain to avoid this probelm and allow the $USER to run it successfully?
Is there any reason this would be a stupid idea from a security perspective?
Thanks!
If this is NOT intended for multiple users, then the simplest (and most secure) method is for the partition to be mounted via fstab with a specified user as owner of the partition and restricted privileges. Namely,
UUID={something} / ext4 defaults,nosuid,uid=1000,gid=1000,fmask=0077,dmask=0077 0 1
That would have the partition mounted every time the system boots, but only the specified user could access that (or anyone with sudo privileges able to assume that identity). If that leaves it too open, you could consider whether to encrypt that partition as well. Implementing that is beyond my experience, but would allow only that user to mount/use/access on basis of the password required to mount. You also have to control the who and how the partition encryption password is changed.
If you pursue the encryption option, you can avoid the fstab approach, and allow the user to mount/unmount at will, since he would be the only one with the password.
The danger with encryption is that when the password is set, it needs to be stored securely, so that administrators can use to recover data when (not if) the organization loses the person that had the "master key".
I'm wondering why my version of mount appears to ignore the effective user ID...
I have this C program owned by root with permission u+s:
int main() {
execl("/bin/mount", "/bin/mount", "/mnt/abc", (char *)0);
}
When a regular user runs it, it complains about not being root. I can work around it like this:
int main() {
setuid(0);
execl("/bin/mount", "/bin/mount", "/mnt/abc", (char *)0);
}
I read that bash changes the effective uid to the real uid as a safety feature. (see Calling a script from a setuid root C program - script does not run as root) However, I don't see why mount should do that. Does anyone know?
My mount version is:
mount from util-linux 2.29.2 (libmount 2.29.2: selinux, btrfs, assert, debug)
This happens because mount is designed to run as suid root.
$ ls -l /bin/mount
-rwsr-xr-x 1 root root 44200 Mar 6 13:31 /bin/mount
^
CDs or floppy drives would typically have the user option set in fstab to allow non-root users to access removable media. mount was made SUID root to support this, and it therefore checks the real UID to determine what you're allowed to do.
I know, passwd has setuid bit set and hence it can modify root owned /etc/shadow file.
[~]$ ls -l `which passwd`
-rwsr-xr-x. 1 root root 27832 Jan 29 2014 /usr/bin/passwd
But how it is making sure that it can modify only the current account's password if logged in as a non-root user.
There are additional UID/GID values available via the geteuid() and similar. The effective UID is the one for whatever user started the program. All the setuid privilege is used for is to change the runtime credentials to that of the effective UID/GUI. Then normal permissions apply.
Scenario:
bob owns directory x
bob has set permissions on x to 777
jim can't write to x. Why?
Actual output:
ls -la .pip/
total 12
drwxrwxrwx 2 user1 user1 4096 May 5 12:03 .
drwx------ 5 user1 user1 4096 May 6 11:34 ..
-rw-rw-rw- 1 user1 user1 2054 May 5 12:48 pip.log
sudo -S -p 'sudo password:' -u "apache" /bin/bash -l -c "mkdir .pip/monkey"
/bin/bash: /home/user1/.bash_profile: Permission denied
mkdir: cannot create directory `.pip/monkey': Permission denied
Ultimately I'm trying to pip install as apache user and that user is not allowed to write the install log, so the process fails. I need to write the log as apache user, but it lives in my user space. I could change the owner, but this process is supposed to work for any user, even new ones, so it's somewhat confusing what I'm supposed to do to achieve this.
UPDATE:
I understand from http://linux.die.net/man/2/path_resolution that it is the fact that apache does not own user1's home directory, so the directory search won't work. Is this the case?
Disclaimer: At the time this answer was composed, the question did not clearly identify working directories. If assumptions documented in the answer are incorrect, the folders mentioned in the answer may need to be adapted accordingly.
It appears that the question asks why user apache cannot operate under:
/home/user1/
It also appears that /home/user1 may have permissions set to drwx------ as these permissions are typically used to help secure private data that can accumulate in the root of the user's home directory.
If the above is true, then it is normal for apache to not be able to work under /home/user1/ because it does not have traversal rights to /home/user. Such rights can be added in various ways. The simplest, but not particularly safe way to do it is something like:
sudo chmod o+x /home/user1
It would then be possible for /home/user1 sub-folder permissions to be tightened and loosened to fit the need. It would be better to use group permissions than world permissions, but you should probably create a special group for this purpose rather than making apache a member of the user1 group. An even better solution would be to use an ACL that grants apache traversal rights to /home/user1 without opening the user's home directory up to a wider audience.
Be careful. Loosening permissions with the aforementioned command can give all users on the box access to sub-directories of the user's home directory if their permissions are not suitably tight.
Note: Security mechanisms on some systems might get annoyed by loosening of user home directory permissions and interfere with manual overrides. This could happen, for example, on a distribution that has msec configured to a relatively high security level. Without more detail given about the system configuration, it is somewhat difficult to anticipate potential problems. For example, unless an exception has been made for particular file system areas, on an msec managed system with high security set, msec will periodically rewrite directory permissions that it monitors if it does not consider the permissions compatible with the configured security level.
-bash-3.2$ man chgrp | head -1
CHGRP(1) User Commands CHGRP(1)
-bash-3.2$ man chown | head -1
CHOWN(1) User Commands CHOWN(1)
following content is from 'man 7 man':
1 Commands
Those commands that can be executed by the user from within a shell.
8 System management commands
Commands like mount(8), many of which only root can execute.
Why CHGRP(1)/CHOWN(1) cannot be used by ordinary user? In my understanding, CHGRP(8)/CHOWN(8) cannot be used by ordinary user.
Letting non-root user to use chown or chgrp would have many problems.
If user were able to chown otheruser ownfile, then after that, he would not be able to access his own file anymore - not good.
If some evil user hijacked your account, he would be able to change permissions on your files such that they are now owned by other user: like evil user or www user. Then, it would be trivial to steal your data.
If any user could successfully call the chown(2) syscall (e.g. thru chrgrp and chown commands) on files not belonging to him, the user-based access protection provided by the Linux kernel would be useless. A malicious user would change ownership of every file whose access is limited to him
Of course, the user could execute the chown command (e.g. by typing /usr/bin/chown file) but if called from an ordinary user these commands will fail (and have a non-zero exit code) because the underlying chown(2) syscall would fail.
NB: as documented, an ordinary user may chgrp to some group he belongs to.
All users can use chgrp change the group of a file they own to other groups they are a member of. Try this, replacing the group name lpadmin with any second group that are in:
touch t; ls -l t; chgrp lpadmin t; ls -l t
The before and after calls to ls will show that the group changed.