I'm studing Set-UID Privileged Programs, and it seems that a program executes with a its own owner privilegies.
Example: passwd can read/write the shadow file because it belongs to a root user. How can i find this kind of information for other programs?
When you set user identification (the 4755 mode) permission to an executable file, a process that runs this file is granted access based on the owner of the file.
In this case you copy /bin/zsh as root user and then set the 4755 mode, /tmp/zsh so will give root privileges to the user that will run the file rather than user privileges.
This special permission allows a user to access files and directories that are normally only available to the owner.
Have you tried to make what you have been asked?
Use getuid(2), geteuid(2), getresuid(2) and the corresponding setuid(2), setreuid(2) appropriately. See also capabilities(7) and credentials(7) & carefully execve(2). Read about proc(5)
Read the Setuid wikipage. A process running a setuid executable can call seteuid to gain privilege.
Related
I have a program called HelloWorld belonging to user test
HelloWorld will create a file HelloWorld.pid in /var/run to keep single instance.
I using following command to try to make test can access /var/run
usermod -a -G root test
However, when I run it, falied
could someone help me?
What are the permissions on /var/run? On my system, /var/run is rwxr-xr-x, which means only the user root can write to it. The permissions do not allow write access by members of the root group.
The normal way of handling this is by creating a subdirectory of /var/run that is owned by the user under which you'll be running your service. E.g.,
sudo mkdir /var/run/helloworld
sudo chown myusername /var/run/helloworld
Note that /var/run is often an ephemeral filesystem that disappears when your system reboots. If you would like your target directory to be created automatically when the system boots you can do that using the systemd tmpfiles service.
Some linux systems store per-user runtime files in /var/run/user/UID/.
In this case you can create your pid file in /var/run/user/$(id -u test)/HelloWorld.pid.
Alternatively just use /tmp.
You may want to use the user's name as a prefix to the pid filename to avoid collision with other users, for instance /tmp/test-HelloWorld.pid.
In Unix, if I run a binary which mucks around with files, does the binary have the same file permissions as myself (the user who ran the binary)?
In most of the cases, the answer is yes!
However this is not true if you have setuid, setgid bits enabled on that binary.
Classic example of binary with the setuid enabled.
ls -ltra `which passwd`
That command would not be able to work, if it could not grant you (the user that execute the command) the same privilege as root during its execution to modify files like /etc/password or /etc/shadow
Have a look at:
https://docs.oracle.com/cd/E19683-01/816-4883/secfile-69/index.html
setuid Permission
When set-user identification (setuid) permission is set on an
executable file, a process that runs this file is granted access based
on the owner of the file (usually root), rather than the user who is
running the executable file. This special permission allows a user to
access files and directories that are normally only available to the
owner.
setgid Permission
The set-group identification (setgid) permission is similar to setuid,
except that the process's effective group ID (GID) is changed to the
group owner of the file, and a user is granted access based on
permissions granted to that group. The /usr/bin/mail command has
setgid permissions
You might also want to have a look at fork and exec if you want to dig a bit further into how does Linux manage processes and subprocesses.
I tried to open /dev/mem.
Accessing /dev/mem needs root permission to open the file.
But I can't use my program in super user. so I changed /dev/mem access permission as 666(Don't consider about security issues!). but still, I cant open the file.
is there any way to open the file in non root mode?
No, there is not. Access to /dev/mem is a privileged operation.
Have you tried adding your user to kmem group?
If you need just read permission it may work.
At your file change the owner and set permissions 4755.
sudo chown root FILE
sudo chmod 4755 FILE
I'm trying to give read permissions to lighttpd access logfiles to normal users which are on the same system.
The permissions are currently:
-rw-r--r-- 1 www-data www-data 211K Feb 28 11:27 /var/log/lighttpd/access.log
So, if I understood correctly others have read permissions. Unfortunately this doesn't seem to work. If I try to read this file with an user account I get:
/var/log/lighttpd/access.log: Permission denied
I already tried to add the user to the group www-data which didn't work as well.
Any hints what I'm doing wrong here?
To access a file, the system needs the execute permission on all the directories containing the file.
In this case it was necessary to issue the chmod o+x /var/log/lighthttps command (after making sure that the user belongs to the "other" part of the permission set).
The "execute" permission for a directory allows you to enter it. The "read" permission for the directory allows you to see the names of the files inside. The interesting thing is that you can give the x permission alone, what means that anyone can access the files inside, but he needs to know its names.
You might not have execute permission for the lighthttpd so the directory does not give the permission to access its containing file.
Use the command to set the execute permission to that directory.
chmod +x /var/log/lighthttpd
-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.