I'm really new about linux so this question is pretty dumb i know. Sorry for that.
I checked the user and group and some of users' uid and gid are different so
I just wanna make them synchronized.
tail -6 /etc/passwd
mysql:x:993:1000::/path
apache:x:1000:1001::/path
user1:x:1001:1002::/path
I'm wondering that it's not the matter if I synchronized uid and gid. Thanks :)
Although you could manually synchronize them in the /etc/passwd file (and then manually update every affected file to the new uid/gid), there is no reason to worry about making the uid and gid the same for each user.
Typically, when people talk about synchronizing uid/gids they are referring to ensuring user accounts on two seperate computers for the same user have the matching uids and matching gids (ie. the two uids match and the two gids match).
Related
What do the functions getresuid(&arg1,&arg2,&arg3) and setresuid(arg1,arg2,arg3) do?
It would be great if a really basic explanation of these functions were given.
From the credentials(7) man page (abridged):
On Linux, each process has the following user and group identifiers:
Real user ID and real group ID. These IDs determine who owns the process.
Effective user ID and effective group ID. These IDs are used by the kernel to determine the permissions that the process will have when accessing shared resources such as message queues, shared memory, and semaphores. On most UNIX systems, these IDs also determine the permissions when accessing files. However, Linux uses the file system IDs for this task.
Saved set-user-ID and saved set-group-ID. These IDs are used in set-user-ID and set-group-ID programs to save a copy of the corresponding effective IDs that were set when the program was executed. A set-user-ID program can assume and drop privileges by switching its effective user ID back and forth between the values in its real user ID and saved set-user-ID.
Those functions get and set all three of those UIDs in one call. And as always, see the full man page for complete details.
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.
I wrote a file manager, and now I want to allow user to enter password if he want's to copy or edit a file that requires sudo. I can just start a new copy of a program with gksudo or sudo and hide the current copy. But is that possible to do in the same process?
I have read mans for geteuid and some other functions but I feel I lack some basic understanding here, because mans do not make much sense to me.
In order to do root-only stuff, process has to start with an effective uid of 0 or have capabilities that allow it to impersonate such euid (CAP_SETUID).
Effective uid is set using the special filesystem attribute, called "setuid" flag:
# ls -l /bin/su
-rws--x--x 1 root root 36720 Mar 28 2013 /bin/su
note the 's' in the file permission flags.
The above means, that when any user runs the su command, it will run on behalf of the executable's owner, in this case root (so the process will run with your normal user id, but effective user id will be that of root user). Thus, such process will be able to do anything root can.
Another, more modern approach, is to give the process select capabilities, such as CAP_SETUID. Those can be set and queried using setcap/getcap commands and allow finer grain control over what process can and can not do. Whether this results in safer system, remains an open question.
https://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_Setuid
Neat overview of possible security issues:
http://forums.grsecurity.net/viewtopic.php?f=7&t=2522&sid=c6fbcf62fd5d3472562540a7e608ce4e#p10271
I'm trying to understand what logic determines whether a user can log in with a particular MLS sensitivity level. At first I suspected that pam_selinux.so reads the /etc/selinux/.../seusers file to understand which user is bound to which seuser and then restricts the user to sensitivities equal to or lower than the high component of the MLS range.
However, after scratching through its source code I found that, after asking the user if he would like to change their security context from the the default context, pam_selinux checks that the new MLS labels are appropriate by calling into the kernel policy.
The following code is in modules/pam_selinux/pam_selinux.c from the Ubuntu libpam-modules 1.1.1-4ubuntu2 package.
static int mls_range_allowed(pam_handle_t *pamh, security_context_t src, security_context_t dst, int debug)
{
struct av_decision avd;
int retval;
unsigned int bit = CONTEXT__CONTAINS;
context_t src_context = context_new (src);
context_t dst_context = context_new (dst);
context_range_set(dst_context, context_range_get(src_context));
if (debug)
pam_syslog(pamh, LOG_NOTICE, "Checking if %s mls range valid for %s", dst, context_str(dst_context));
retval = security_compute_av(context_str(dst_context), dst, SECCLASS_CONTEXT, bit, &avd);
context_free(src_context);
context_free(dst_context);
if (retval || ((bit & avd.allowed) != bit))
return 0;
return 1;
}
It seems to me that this check is actually checked in the kernel policy, seen in the security_compute_av() call. This turned my understanding of SELinux login on my head.
So, could someone please explain:
How is the validity of a user-chosen login security level determined?
How exactly is that logic implemented in the policy, in pam_selinux, and in the kernel?
Currently, I'm not too interested in type enforcement multi, categories security, or role based access control, so no need to explain how those components are validated if they don't affect MLS sensitivities.
Given that I also share the "SELinux folds my brain in half" problem, I think I can help. First and foremost, you need to remember the difference between discretionary access control and mandatory access control. You also need to remember that user space defines a lot of things, but the kernel gets to enforce them.
First, here is a partial list of user space versus kernel space issues:
User space defines a valid user ID, the kernel creates processes owned by that user ID (the number, not the name)
User space puts permissions and ownership on a file on an ext3/4 file system, the kernel enforces access to that file based upon the file inode and every subsequent parent directory inode
If two users share the same user ID in /etc/passwd, the kernel will grant them both the same privileges because enforcement is done by the numeric identifier, not the textual one
User space requests a network socket to another host, the kernel isolates that conversation from others on the same system
With SELinux, user space defines roles, logins, and users via semanage and the kernel compiles those down into a large Access Vector Cache (AVC) so that it can enforce role-based access control and mandatory access control
Also under SELinux, a security administrator can use semanage to define a minimum and maximum security context. If you are in a multi-level security (MLS) configuration, and during log in, the users picks some context, then the kernel measures that against the AVC to determine if it is allowed.
What would probably help this make sense is to be in a multi-level security configuration. I took the class on SELinux and we touched it for about two hours. Most people don't want to go there. Ever. I've been in an MLS configuration quite a bit, so I understand the reasoning behind the coding decision you were chasing, but I agree that tinkering with MLS is a pretty painful way to understand how and why PAM works like it does.
Discretionary Access Control (DAC) is where user space, especially non-root users, can define who can access data that they control and in what fashion. Think file permissions. Because users control it, there is a trivial amount of effort needed to allow one user to see processes and/or files owned by another user. Normally, we don't care that much because a good administrator assumes that any one user could compromise the whole box and so all users are trusted equally. This might be very little trust, but there is still some level of trust.
Mandatory Access Control (MAC) is where user space is not to be trusted. Not all users are created equal. From a non-MLS perspective, consider the case where you have a web server and a database server on the same hardware (it will never survive the Slashdot effect). The only time the two processes communicate is over a dedicated connection channel over TCP. Otherwise, they must not even know that the other exists. We would operate them under two different contexts and the kernel will enforce the separation. Even looking at the process table or wandering around the hard drive as root will not get you any closer unless you change contexts.
In an MLS configuration, I can't tell you how many times I've tried to get random combinations of sensitivity and context only to be rebuffed for picking an invalid combination. It can be very frustrating because it takes a lot of exploring of your existing policy (/etc/selinux/policy/src/policy/policy under Red Hat 5) to know what it or is not allowed.
Under a Strict configuration, I can clearly see why all of this is overkill. And that's simply because SELinux is overkill for simple situations. It has other features though that partially redeem it, but chief among them is fine grained access control that enforces administrator-set permissions. One area that this is used the most is in restricting service daemons to just their essential access needed. It is painful to set up a new daemon, but it keeps trivial exploitations like a shared library exploit from going any further because the process in question may be assigned to a role that won't let it run non-daemon commands like /bin/ls or a shell. Exploits don't do you much good in those situations.