clarification on setuid

[magnesium]

From reading the FreeBSD documentation, it seems like the setuid permission is given to a script or a program and allows it to run as another UID. The reason behind this, using the passwd command as an example, is to allow a non-root user to change their password without changing anyone else's password (passwd prevents one user from being able to change other user's passords). Is this correct? Is the setuid permission used for any other purpose than to allow a user to use a program to access a file as another user?

A follow on question (if the above is incorrect, ignore this question), would implementing finer-grained file permissions (different permissions for different portions of a file) remove the necessity for the setuid permission? For example, in the password database, each user would have permission to edit their own password, but not any other user's password. This way, passwd could run with the permissions of the user that's changing their password. I realize that this would be a huge rewrite, but beyond that, is this a possible solution, or would it just create more problems than it would solve?

 

[SirDice]

A follow on question (if the above is incorrect, ignore this question), would implementing finer-grained file permissions (different permissions for different portions of a file) remove the necessity for the setuid permission? For example, in the password database, each user would have permission to edit their own password, but not any other user's password. This way, passwd could run with the permissions of the user that's changing their password. I realize that this would be a huge rewrite, but beyond that, is this a possible solution, or would it just create more problems than it would solve?

It's a possible solution, unfortunately you can't give different permissions on different parts of a file. It's an all or nothing deal, permissions are set on the entire file. It would be an administrative disaster if parts of a file could have different permissions.

 

[fluca1978]

A follow on question (if the above is incorrect, ignore this question), would implementing finer-grained file permissions (different permissions for different portions of a file) remove the necessity for the setuid permission? For example, in the password database, each user would have permission to edit their own password, but not any other user's password. This way, passwd could run with the permissions of the user that's changing their password. I realize that this would be a huge rewrite, but beyond that, is this a possible solution, or would it just create more problems than it would solve?

It will introduce a lot of problems. If I get it right you should have to create a password database owned by, let's say, a pwd_daemon user. The passwd(1) program will then check the current uid and modify only such row. Up to here it is not that big deal, but the passwd(1) program has to be able to write the file in any part, and therefore must run with a suid set to pwd_daemon. On the other hand, you would have to install a lot of per-user specific programs and/or configuration files that gives each user the capability to modify only their data....system mess!
Moreover, remember that passwd(1) is an example, but other services could require suid even when not dealing with files.

 

[magnesium]

It's a possible solution, unfortunately you can't give different permissions on different parts of a file. It's an all or nothing deal, permissions are set on the entire file. It would be an administrative disaster if parts of a file could have different permissions.

The kernel and all setuid programs would obviously need to be modified to work with this method. Also, it would obviously take some getting use to. Assuming the interfaces (text editors, etc) are setup to clearly display the permissions for each part of files, could you explain how it would be an administrative disaster?

It will introduce a lot of problems. If I get it right you should have to create a password database owned by, let's say, a pwd_daemon user. The passwd(1) program will then check the current uid and modify only such row. Up to here it is not that big deal, but the passwd(1) program has to be able to write the file in any part, and therefore must run with a suid set to pwd_daemon. On the other hand, you would have to install a lot of per-user specific programs and/or configuration files that gives each user the capability to modify only their data....system mess!
Moreover, remember that passwd(1) is an example, but other services could require suid even when not dealing with files.

For a given user, why does passwd(1) have to be able to edit any part of the password file? If userA ran it, it would be able to edit userA's password only, then if userB ran it, it would be able to edit userB's password only.

I don't think you'd have to install any more programs and/or configuration files, just have to modify them to work with this new method. Could you explain more why you think user specific programs/configuration files would be needed?

Could you give an example of when a program/script would need setuid permissions other than to edit files?

 

[SirDice]

The kernel and all setuid programs would obviously need to be modified to work with this method. Also, it would obviously take some getting use to. Assuming the interfaces (text editors, etc) are setup to clearly display the permissions for each part of files, could you explain how it would be an administrative disaster?

Because people are already creating one big mess with just an ACL on the file. Imagine what happens when that file has multiple parts, each with their own ACL.

For a given user, why does passwd(1) have to be able to edit any part of the password file? If userA ran it, it would be able to edit userA's password only, then if userB ran it, it would be able to edit userB's password only.

And how is a service desk going to reset a user's password if it can't access it?

Could you give an example of when a program/script would need setuid permissions other than to edit files?

dice@molly:~> ll /sbin/ping
-r-sr-xr-x  1 root  wheel  28016 Apr 22 18:27 /sbin/ping

Your mission, if you choose to accept it, is to find out why ping(8) needs suid :e

 

[Uniballer]

One implementation problem is that the current /etc/passwd file format uses a variable amount of data for each entry. This is a problem because the size of each entry could change, and the permissions/ownership of that entry's range would have to change with it. Ugly mess.

 

[anon12b]

Openwall TCB is an implementation of SGID-only passwd(1). You need the group to access /etc/tcb, but your actual password is writable by you. It stops the user randomly editing the file, and limits any flaws in passwd(1) to letting you mess with your password. They have the same concept for their crontabs.

 

[magnesium]

Because people are already creating one big mess with just an ACL on the file. Imagine what happens when that file has multiple parts, each with their own ACL.

I didn't realize setting permissions was such a big problem. So it's a matter of this method exasperating an existing problem, not that this method creates a new problems, correct?

And how is a service desk going to reset a user's password if it can't access it?

One way would be to create a group for the service desk and give that group edit privileges over the appropriate users' password.

dice@molly:~> ll /sbin/ping
-r-sr-xr-x  1 root  wheel  28016 Apr 22 18:27 /sbin/ping

Your mission, if you choose to accept it, is to find out why ping(8) needs suid :e

I think I will accept this mission, although I may regret this decision

One implementation problem is that the current /etc/passwd file format uses a variable amount of data for each entry. This is a problem because the size of each entry could change, and the permissions/ownership of that entry's range would have to change with it. Ugly mess.

This would have to be solved, but I don't think it'd be a road block, just a speed bump (maybe a large one).

Openwall TCB is an implementation of SGID-only passwd(1). You need the group to access /etc/tcb, but your actual password is writable by you. It stops the user randomly editing the file, and limits any flaws in passwd(1) to letting you mess with your password. They have the same concept for their crontabs.

Originally, I was thinking to also eliminate setgid as well. If both setuid and setgid were eliminated, then a user would be able to randomly edit the their password, including setting invalid values. This would be a downside to this method, but it may be worth it, or not.