clarification on setuid

magnesium · #1 May 8th, 2012, 07:07

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** · #2 May 8th, 2012, 07:26

Quote:

Originally Posted by magnesium

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 · #3 May 8th, 2012, 08:50

Quote:

Originally Posted by magnesium

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 · #4 May 8th, 2012, 15:22

Quote:

Originally Posted by SirDice

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?

Quote:

Originally Posted by fluca1978

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** · #5 May 8th, 2012, 15:27

Quote:

Originally Posted by magnesium

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.

Quote:

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?

Quote:

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

Code:

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

Uniballer · #6 May 8th, 2012, 16:02

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 · #7 May 8th, 2012, 20:49

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 · #8 May 9th, 2012, 08:58

Quote:

Originally Posted by SirDice

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?

Quote:

Originally Posted by SirDice

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.

Quote:

Originally Posted by SirDice

Code:

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

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

Quote:

Originally Posted by 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.

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).

Quote:

Originally Posted by 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.

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.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Need help with setuid	Slurp	FreeBSD Development	2	October 7th, 2011 08:11
[Solved] setuid issues	Beeblebrox	Installation and Maintenance of FreeBSD Ports or Packages	2	March 13th, 2011 12:31
Apache Maintenance - Clarification	jaymax	Installation and Maintenance of FreeBSD Ports or Packages	6	August 22nd, 2010 07:16
[Solved] xorg setuid	ssn_bsd	X.Org	6	October 29th, 2009 15:47