I am developing one security base software for Linux platform using C and CPP. I want to restrict all users (even root user) also to modify the file. i.e No one can modify the file.
Modifying means no-one can write to the file, move the file or remove the file etc.
More precisely:
I have a file named as a.txt in directory /home/ and I want to do something to this file so that no one can write into this file, remove this file or move this file.
But can read the file.
I tried chattr command:
chattr +i /home/a.txt
It solved my problem for other users but when I switched to superuser i.e root user into terminal and I fired command:
chattr -i /home/a.txt
So /home/a.txt file become mutable. root user can change file immutable to mutable. So the problem is not solved for root user.
I want to do something to this file, so even root user can't modify this file.
I already ask this question at Unix&Linux and askUbuntu and did not get any answer.
In general, the definition of the root user in Unix systems is that no permission checking is done by the kernel when the user is root (with some insignificant exceptions).
So, if you want to prevent root from doing something, you have to write a kernel module that does that. Indeed, most security-related software has kernel components. And this will be harder than you think - root can basically unmount the filesystem and mount it on another machine, or boot with a kernel that doesn't include your module.
There are already a few security-related kernel modules that you can look into: SELinux, AppArmor etc. (also Tomoyo and Smack, but they don't seem helpful in this case). Depending on your requirement, they might be sufficient.
Put your app in an appliance with disk encryption.
How to change the system time and date in QML? I thought this might work from an example, though I have this doubt where the object is being sent. It didn't work. Can some one let me know how to that? Following is my code:
var time = new Date()
time.setHours(hour)
time.setMinutes(minute)
time.setSeconds(secs)
You generally cannot change the system time without root permission, and setting the system time is a whole-system operation for sysadmins. See settimeofday(2) and adjtimex(2). See also credentials(7) & capabilities(7).
(So it is not a matter of using Qt or something else; any library using settimeofday or adjtimex needs root permission)
Read also time(7).
And you generally should not change the system time, but have some daemon using NTP to adjust it continuously.
Your code is just changing the value of some variable holding some time. It is not changing the system time.
The sysadmin could change the time e.g. with date(1) used with -s which requires root permission and uses settimeofday internally. See also hwclock(8).
Notice that GUI applications should generally not be run as root (and Qt or GTK don't want to be run as root).
If you develop some embedded system and you want the user to set the time, you could consider writting some small specialized setuid executable which uses settimeofday(2) and have your GUI application run it (e.g. with QProcess). Be very careful when coding a setuid program (so read ALP or some good book on Linux system programming), since you could easily get vulnerabilities. Be aware that setuid is the basic mechanism (used by /bin/login, /bin/su, /usr/bin/sudo etc...; it is also used in Android systems or any Unix-derived system) to acquire or change permission. It is tricky to use, so do spend time to understand it.
Perhaps your init or systemd might be configured to ease such a task....
(you need to describe your entire system much more to get more help)
I have a program (https://github.com/raboof/connbeat) that relies on /proc/[pid]/fd/* to find processes given a (networking) inode.
/proc/[pid]/fd can only be read by root, but I'd like to drop privileges as much as possible for security.
Is there some way I could (efficiently) get to the relationship between processes and inodes without requiring full root rights? Perhaps some syscall that I can selectively give access to using capabilities?
To be able to read fd's of all the processes you need:
CAP_DAC_READ_SEARCH - for access to /proc/[pid]/fd
CAP_SYS_PTRACE - to read symlinks under /proc/[pid]/fd/*
You can restrict your program to just these two capabilities. Then you can access the information in question using ordinary API calls like readdir() or readlink() or whatever else you prefer.
For a broader description of these two capabilities please refer to capabilities(7)
I am already aware of the real user id. It is the unique number for a user in the system.
On my system, my uid is
$ echo $UID
1014
$
What do the other two IDs stands for?
And what is the use of effective user id and saved user id and where do we use them in the system?
The distinction between a real and an effective user id is made because you may have the need to temporarily take another user's identity (most of the time, that would be root, but it could be any user). If you only had one user id, then there would be no way of changing back to your original user id afterwards (other than taking your word for granted, and in case you are root, using root's privileges to change to any user).
So, the real user id is who you really are (the one who owns the process), and the effective user id is what the operating system looks at to make a decision whether or not you are allowed to do something (most of the time, there are some exceptions).
When you log in, the login shell sets both the real and effective user id to the same value (your real user id) as supplied by the password file.
Now, it also happens that you execute a setuid program, and besides running as another user (e.g. root) the setuid program is also supposed to do something on your behalf. How does this work?
After executing the setuid program, it will have your real id (since you're the process owner) and the effective user id of the file owner (for example root) since it is setuid.
The program does whatever magic it needs to do with superuser privileges and then wants to do something on your behalf. That means, attempting to do something that you shouldn't be able to do should fail. How does it do that? Well, obviously by changing its effective user id to the real user id!
Now that setuid program has no way of switching back since all the kernel knows is your id and... your id. Bang, you're dead.
This is what the saved set-user id is for.
I'll try to explain step by step with some examples.
Short background
Each process has its own 'Process credentials' which include attributes like PID, the PPID, PGID, session ID and also the real and effective user and group IDs:
RUID, EUID, RGID, EGID.
We'll focus on those.
Part 1: Understand UID and GID
Now I'll log into a shell with my credentials and run:
$ grep $LOGNAME /etc/passwd
rotem:x:1000:1000:rotem,,,:/home/rotem:/bin/bash
You can see my logname (rotem), the UID and GID which are both 1000, and other details like the shell I'm logged into.
Part 2: Understand RUID and RGID
Every process has an owner and belongs to a group.
In our shell, every process that we'll now run will inherit the privileges of my user account and will run with the same UID and GID.
Let's run a simple command to check it:
$ sleep 10 & ps aux | grep 'sleep'
And check for the process UID and GID:
$ stat -c "%u %g" /proc/$pid/
1000 1000
Those are the real user ID (RUID) and real group ID (RGID) of the process.
(*) Check other options to view the UID and GID and ways to get this in a single line.
For now, accept the fact that the EUID and EGID attributes are 'redundant' and just equals to RUID and RGID behind the scenes.
Part 3: Understand EUID and EGID
Let's take the ping command as an example.
Search for the binary location with the which command then run ls -la:
-rwsr-xr-x 1 root root 64424 Mar 10 2017 ping
You can see that the owner and the group of the file are root. This is because the ping command needs to open up a special socket and the Linux kernel demands root privilege for that.
But how can I use ping if I don't have root privilege?
Notice the 's' letter instead of 'x' in the owner part of the file permission.
This is a special permission bit for specific binary executable files (like ping and sudo) which is known as setuid.
This is where EUID and EGID come into play.
What will happen is when a setuid binary like ping executes, the process changes its Effective User ID (EUID) from the default RUID to the owner of this special binary executable file which in this case is - root.
This is all done by the simple fact that this file has the setuid bit.
The kernel makes the decision whether this process has the privilege by looking on the EUID of the process. Because now the EUID points to root, the operation won't be rejected by the kernel.
Notice: On latest Linux releases the output of the ping command will look different because of the fact that they adopted the Linux Capabilities approach instead of this setuid approach - for those who are not familiar - read here.
Part 4: What about SUID and SGID?
The Saved user ID (SUID) is being used when a privileged process is running (as root for example) and it needs to do some unprivileged tasks.
In that case, the effective UID (EUID) from before will be saved inside SUID and then changed to an unprivileged task. When the unprivileged task is completed, the EUID will be taken from the value of SUID and switch back to privileged account.
Real user id is the user that spawned the process.
Effective user id is the user determined by the setuid bit on the binary being executed.
Here are some truths about uids and euids, with the manual sources for each:
You can use euid when you're spawning as root and you need to temporarily drop privileges and still be able to regain root privileges after, as in man setuid(2):
Thus, a set-user-ID-root program wishing to temporarily drop root privileges, as‐
sume the identity of an unprivileged user, and then regain root privileges after‐
ward cannot use setuid(). You can accomplish this with seteuid(2).
You can also use it to raise your privileges from a setuid program. If your effective user id is root, everything will react as if you are root, except I think the only exception is file access checks will check your real user id rather than effective user id, which is a source of confusion, as in man access(2):
The check is done using the calling process's real UID and GID, rather
than the effective IDs as is done when actually attempting an operation
(e.g., open(2)) on the file. Similarly, for the root user, the check
uses the set of permitted capabilities rather than the set of effective
capabilities; and for non-root users, the check uses an empty set of
capabilities.
When calling bash, it doesn't propagate euid unless you pass -p as in man bash(1):
If the shell is started with the effective user (group) id not equal to the real
user (group) id, and the -p option is not supplied, no startup files are read,
shell functions are not inherited from the environment, the SHELLOPTS, BASHOPTS,
CDPATH, and GLOBIGNORE variables, if they appear in the environment, are ignored,
and the effective user id is set to the real user id. If the -p option is sup‐
plied at invocation, the startup behavior is the same, but the effective user id
is not reset.
When using sudo, both effective and real user id's are set as in man sudo(8):
When sudo executes a command, the security policy specifies the execution environ‐
ment for the command. Typically, the real and effective user and group and IDs are
set to match those of the target user, as specified in the password database, and
the group vector is initialized based on the group database (unless the -P option
was specified).
This is how I understand it. The file an user executes(equivalent to starting a process) will have a RUID equal to that user's id. Important thing to note here is that the uid which created a file is not the same as the uid that executes the file. They can be the same or different. So, RUID may vary depending on the UID that executes the file. When a file has the setuid bit on it, whenever an uid executes that file, that uid will temporary be replaced with the file owner's uid. So, if we have a file owned by uid 456 and has the setuid bit on it, whenever uid 123 executes that file, that file will be executed with the uid 456. In this scenario, uid 123 is the RUID and uid 456 is the EUID.
It seems that htop shows all running processes to every user, and process names in htop contain all the file names that I include in the command line. Since I usually use very long file names that actually contains a lot of detailed information about my project, I do not want such information to be visible to every one (but I am OK that other users see what software that I am running).
How can I hide the details in the process name?
How can I hide the details in the process name?
Since kernel 3.3, you can mount procfs with the hidepid option set to 1 or 2.
The kernel documentation file proc.txt describe this option:
The following mount options are supported:
hidepid= Set proc access mode.
hidepid=0 means classic mode - everybody may access all /proc directories
(default).
hidepid=1 means users may not access any /proc directories but their own. Sensitive files like cmdline, sched*, status are now protected against other users. This makes it impossible to learn whether any user runs specific program (given the program doesn't reveal itself by its behaviour). As an additional bonus, as /proc//cmdline is unaccessible for other users, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.
hidepid=2 means hidepid=1 plus all /proc will be fully invisible to other users. It doesn't mean that it hides a fact whether a process with a specific pid value exists (it can be learned by other means, e.g. by "kill -0 $PID"), but it hides process' uid and gid, which may be learned by stat()'ing /proc// otherwise. It greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, etc.