I've been reading in most hardening guides for Linux, that you should check for files and directories without valid user or valid group. What I can't find, is how this could be used for an attack, or how this could be a weakness, besides it being "improper".
Add a comment
|
3 Answers
Every file should belong to a user or group, for the primary reason of enforcing file permissions.
A basic but very key concept of protecting a system is the principle of least privilege: allow users minimal access needed to get the job done.
For example, your web development team might need access to your /www directory, but they should not need to have access your system files. Setting up proper ownership and access control for your files makes it easier to enforce the principle of least privileged by limiting the amount of access each user is allowed.
-
-
1(Cc @user857990) While true, this doesn't seem to relate to the question. The principle of least privilege implies checking that files are only accessible to the principals who are supposed to have access. This means looking at both ownership and permission, but it applies to all files “with” users and groups. Aug 20, 2012 at 18:09
-
1
Files always have a owner-id and a group-id. But if the files are copied from another system (e. g. extracted from a tar archive), there may be no name assigned to those ids.
At a later time a new user or group may be created which gets the next available id. This id, however, may be the same id as the one used improperly before.
As a result the new user/group gets access to those files.
answered Aug 20, 2012 at 7:56
-
but how does that affect security? From your answer it looks like the only downside is, that a user gets the files of another user (which is bad, but still, I was wondering if there are bigger implications) Aug 22, 2012 at 19:53
The wording of this question is a bit strange: each file belongs to exactly one user and exactly one group. Each file has separate sets of permissions (rwx) for the owning user, the owning group (minus the owning user if he's in the group), and others. It's impossible for a file not to have that one user and group.
If the filesystem has ACLs, there may be more users and groups with specified permissions on each file.
Users and groups are encoded as integers in the filesystem. These integers are called user ID (uid) and group ID (gid). The association between these integers and user and group names lives at a higher level, they are provided by the standard library. The associations are recorded in local databases such as /etc/passwd and /etc/group, and in network databases such as NIS and LDAP. These databases define the scope in which a user or group is valid. Generally that scope is the local machine for a local database and a network of machines using the same database for a network database, but there is a lot of potential for more complex situations; for example it is common to have system users with a per-machine scope and real users provided by a network database and shared over many machines.
Occasionally you may see a file that belongs to a user or group that doesn't have a name. There can be many reasons for this, but most are an indication that something is wrong.
- The user or group is provided by a network database that is currently inaccessible.
- A user or group was removed, but there are still files belonging to it.
The file is viewed in the wrong scope:
- over a remote filesystem protocol such as NFS, the server and the client have different user or group databases, and the remote filesystem does not perform the remapping that would be necessary;
- on a removable disk which was moved between systems that use different databases;
- extracted from an archive created in a different scope;
- in a virtual environment (which could be anything from chroot up) which uses different databases.
Note that in all of these cases except for the temporarily unavailable network database, the fact that you see a number instead of seeing the wrong name is down to luck. If a user ID has been removed and reassigned, the new user with this ID will have control over the files left over from the old user with this ID — as far as the OS is concerned, this is the same user. If a file is viewed in the wrong user scope, and the ID happens to be assigned to different user names in the two scopes, the you won't get any warning. So while seeing an unnamed user or group is a symptom that something is wrong, you cannot rely on the symptom appearing. Unnamed users and groups should be part of a filesystem audit, but they aren't the main focus.
answered Aug 20, 2012 at 18:07
Gilles 'SO- stop being evil'Gilles 'SO- stop being evil'
51.8k14 gold badges122 silver badges182 bronze badges
-
Is there any reason why ids should get recycled in systems with low turnover? If user "fred" with ID 57 leaves, why not simply rename the account to "reserved57" and never use ID 57 ever again?– supercatJan 5, 2018 at 3:27
-
@supercat Some admins do that. Some don't, either because they like to keep the system clean or because it doesn't scale — if you don't delete accounts, then eventually, the user database will be almost only closed accounts. Jan 5, 2018 at 20:33
-
Some systems have much higher turnover than others, but I've seen account iDs reused even on systems which create less than a dozen accounts per year. Unless a system will have over a billion different users in its lifetime, there should never be any need to create a new user ID that's less than the highest existing one, and "reserved" users could be deleted whenever some higher-numbered user exists.– supercatJan 5, 2018 at 20:51