Re: saved IDs and exec (standard violation?)
Roland McGrath [EMAIL PROTECTED] writes: The only drawback I see is in the case when svuid!=euid or svgid!=egid, and you are executing an sugid file. The user will reauthenticate everything for the svuid=euid, svgid=egid change and then the filesystem will reauthenticate everything again to do the suid/sgid. So, a sugid program that execs another sugid program directly without an intervening exec of a non-suid program--a pretty rare event, I would guess. I'm happy to gunk up setuid execs with however many extra RPCs as long as normal execs can remain speedy. But there might be a security reason why we have to force the change to be made. But I can't possibly see what that would be. I don't think any concept of security is sensical for non-sugid execs with EXEC_SECURE. The user who made the call will always be able to grab the process by its scrawny little task port and diddle its ports out the wazoo. Exactly my thinking. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
On Sat, May 11, 2002 at 10:28:19PM -0400, Roland McGrath wrote: Just to keep the record straight, I was talking about having the filesystem implementing file_exec do it (that's where the only auth diddling is, the exec server doesn't do it). But having the user do it is a better plan. I don't know why I didn't think of that in the first place. It avoids the whole issue of the filesystem having to either trust or deal with a user-supplied auth port even with a svuid/svgid change is required. I agree. This was actually my first thought about how to fix it (It seems to be merely an issue of the default behaviour in glibc, ...), because obviously the task already has all the privileges it is leaking, and as such there is no real security leak in the system, but only at the user's side. In Unix, there doesn't seem to be a way to change the saved ID other than changing the effective ID and do a fork(). In the Hurd, we can do better, it seems. Maybe we can even have setsuid,getsuid,setsgid,getsgid? Seems to be a straightforward addition at least, although I am not sure of what use it will be when exec resets them. The only drawback I see is in the case when svuid!=euid or svgid!=egid, and you are executing an sugid file. I agree, this is not a common thing to do at all. Might happen with a game that starts a sound daemon, or things like that. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
On Sun, May 12, 2002 at 02:24:24PM +0200, Marcus Brinkmann wrote: In Unix, there doesn't seem to be a way to change the saved ID other than changing the effective ID and do a fork(). exec(), not fork(), of course. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
Yes, that seems to be a bona fide bug based on a misreading of the standard. The language is not really all that clear, but the behavior of other systems is consistent so we can tell how to read it. That is, svuid=euid and svgid=egid are done *on every exec*, not just on s[ugi]id ones. This is unfortunate for the Hurd, because as things are defined now it would require some additional RPCs to the auth server for every exec. This has several issues. First, it's just more RPCs to slow the exec down. For a non-secure exec, the filesystem really doesn't care if the auth port passed in file_exec is totally bogus. So you have to treat this differently, especially for things like fakeauth to have a hope of working. The common case is that no IDs need to change because euid==svuid and egid==svgid already, so you would like to avoid the whole mess for that. But as things are specified now, there is no way to know that without doing an auth_getids RPC on the auth port. The only thing I see is to presume that the authentication of the file port being used for file_exec matches the auth port in question, and so the filesystem can just examine its own record to check whether anything needs to be done. That would be a new assumption in the semantics of file_exec now, but it's an assumption that's true for all existing uses of file_exec AFAIK. We could add a new EXEC_* flag bit to assert this is ok, which execve et al would use. (The meaning of this flag being that if the receiving protid has svuid==euid and svgid==egid then the auth port doesn't need to be modified for a non-sugid exec.) I think the first thing to do, regardless of all else, is to change the fshelp_exec_reauth interface so that the entire question can be resolved in that function. I propose to change netfs and diskfs so they call fshelp_exec_reauth for every exec, not just sugid ones. I also want to replace the callback function by just passing the iouser; that is all that's needed to replace the existing two (identical) callback functions used by netfs/diskfs, and gives the necessary information for the plan I described above. I'm inclined to make this change now just because it reduces some code duplication and simplifies some unnecessary hair, without necessarily changing the behavior at all. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
Roland McGrath [EMAIL PROTECTED] writes: Yes, that seems to be a bona fide bug based on a misreading of the standard. The language is not really all that clear, but the behavior of other systems is consistent so we can tell how to read it. That is, svuid=euid and svgid=egid are done *on every exec*, not just on s[ugi]id ones. Oh this is horrible. Sigh. However, in the normal case, the ids don't change. Is there a security reason we should not allow the user to decide for themselves? ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
Oh this is horrible. Sigh. However, in the normal case, the ids don't change. Is there a security reason we should not allow the user to decide for themselves? Allow the user to decide for themselves does not have a precise meaning to me in this context. Please specify. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
Roland McGrath [EMAIL PROTECTED] writes: Oh this is horrible. Sigh. However, in the normal case, the ids don't change. Is there a security reason we should not allow the user to decide for themselves? Allow the user to decide for themselves does not have a precise meaning to me in this context. Please specify. Sorry. I meant to have the library do the change itself in execve when it's needed (since usually it's a nop) instead of expecting the exec server to do it. But there might be a security reason why we have to force the change to be made. But I can't possibly see what that would be. Thomas ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: saved IDs and exec (standard violation?)
Sorry. I meant to have the library do the change itself in execve when it's needed (since usually it's a nop) instead of expecting the exec server to do it. Just to keep the record straight, I was talking about having the filesystem implementing file_exec do it (that's where the only auth diddling is, the exec server doesn't do it). But having the user do it is a better plan. I don't know why I didn't think of that in the first place. It avoids the whole issue of the filesystem having to either trust or deal with a user-supplied auth port even with a svuid/svgid change is required. The only drawback I see is in the case when svuid!=euid or svgid!=egid, and you are executing an sugid file. The user will reauthenticate everything for the svuid=euid, svgid=egid change and then the filesystem will reauthenticate everything again to do the suid/sgid. So, a sugid program that execs another sugid program directly without an intervening exec of a non-suid program--a pretty rare event, I would guess. But there might be a security reason why we have to force the change to be made. But I can't possibly see what that would be. I don't think any concept of security is sensical for non-sugid execs with EXEC_SECURE. The user who made the call will always be able to grab the process by its scrawny little task port and diddle its ports out the wazoo. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
