Prev: Dealing with different number of fields in a file
Next: Linuxrc and nash
From: Seebs on 29 Apr 2010 12:56
On 2010-04-29, Geoff Clare <geoff(a)clare.See-My-Signature.invalid> wrote:
> There's no requirement for privileges to be all-or-nothing as in
> the old "superuser" privilege model. For example, a process could
> have appropriate privilege to chown() files without having appropriate
> privilege for other things such as killing processes.

Oh, interesting! I picked up my understanding from man pages which
kept referring to "the process's effective user id is the user id of
the user with appropriate privileges" or some such.

So this suggests that it is possible to have any of several options:

* You cannot chown a file.
* You can chown a file, but doing so strips setuid.
* You can chown a file, and this does not strip setuid.

So apparently an implementation is not prohibited from allowing ordinary
users to give each other setuid binaries?

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: pk on 29 Apr 2010 12:59
Seebs wrote:

> On 2010-04-29, Geoff Clare <geoff(a)clare.See-My-Signature.invalid> wrote:
>> There's no requirement for privileges to be all-or-nothing as in
>> the old "superuser" privilege model. For example, a process could
>> have appropriate privilege to chown() files without having appropriate
>> privilege for other things such as killing processes.
>
> Oh, interesting! I picked up my understanding from man pages which
> kept referring to "the process's effective user id is the user id of
> the user with appropriate privileges" or some such.
>
> So this suggests that it is possible to have any of several options:
>
> * You cannot chown a file.
> * You can chown a file, but doing so strips setuid.
> * You can chown a file, and this does not strip setuid.
>
> So apparently an implementation is not prohibited from allowing ordinary
> users to give each other setuid binaries?

There's also another unclear (to me of course) point in the POSIX
description of chmod():

"If the specified file is a regular file, one or more of the S_IXUSR,
S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not
have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID
(S_ISGID) bits of the file mode shall be cleared upon successful return
from chown()."

Now the keyword here is "successful". If "the process does not have
appropriate privileges", how can the call to chown() ever be successful?

It would seem that the above case can never happen. But it's also possible
(and probably more likely) that I'm overlooking something.
From: Seebs on 29 Apr 2010 13:18
On 2010-04-29, pk <pk(a)pk.invalid> wrote:
> There's also another unclear (to me of course) point in the POSIX
> description of chmod():
>
> "If the specified file is a regular file, one or more of the S_IXUSR,
> S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not
> have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID
> (S_ISGID) bits of the file mode shall be cleared upon successful return
> from chown()."
>
> Now the keyword here is "successful". If "the process does not have
> appropriate privileges", how can the call to chown() ever be successful?
>
> It would seem that the above case can never happen. But it's also possible
> (and probably more likely) that I'm overlooking something.

Possibly they're distinguishing between "have appropriate privileges (to
call chown)" and "have appropriate privileges (to preserve the set*id bits)".

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Geoff Clare on 30 Apr 2010 08:49
pk wrote:

> Seebs wrote:
>
>> So apparently an implementation is not prohibited from allowing ordinary
>> users to give each other setuid binaries?
>
> There's also another unclear (to me of course) point in the POSIX
> description of chmod():
>
> "If the specified file is a regular file, one or more of the S_IXUSR,
> S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not
> have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID
> (S_ISGID) bits of the file mode shall be cleared upon successful return
> from chown()."
>
> Now the keyword here is "successful". If "the process does not have
> appropriate privileges", how can the call to chown() ever be successful?

A non-privileged user can use chown() to change just the group ID
(e.g. by specifying -1 as the new user ID).

POSIX also allows for the possibility that systems might support
non-conforming filesystems for which _POSIX_CHOWN_RESTRICTED is off.
That's why the chown() description has some text that is conditional
on _POSIX_CHOWN_RESTRICTED despite the fact that (since 2001) POSIX
mandates _POSIX_CHOWN_RESTRICTED in conforming environments:

If _POSIX_CHOWN_RESTRICTED is in effect for path:

* Changing the user ID is restricted to processes with appropriate
privileges.

* Changing the group ID is permitted to a process with an
effective user ID equal to the user ID of the file, but without
appropriate privileges, if and only if owner is equal to the
file's user ID or (uid_t)-1 and group is equal either to the
calling process' effective group ID or to one of its supplementary
group IDs.

--
Geoff Clare <netnews(a)gclare.org.uk>


From: Jonathan de Boyne Pollard on 1 May 2010 00:07
>
>>
>> Here's the definition from POSIX:
>>
>>> 3.20 Appropriate Privileges
>>>
>>> An implementation-defined means of associating privileges with a
>>> process with regard to the function calls, function call options,
>>> and the commands that need special privileges. There may be zero or
>>> more such means. These means (or lack thereof) are described in the
>>> conformance document.
>>>
>> There's no requirement for privileges to be all-or-nothing as in the
>> old "superuser" privilege model. For example, a process could have
>> appropriate privilege to chown() files without having appropriate
>> privilege for other things such as killing processes.
>>
> So in the hypothetical case at hand, where the file owner is allowed
> to change ownership of the file, would a "chown" process started by
> that user be classified as "having appropriate privileges" or not?
>
There are two common models:

*

The "superuser" model, mentioned by M. Clare and with which we are
all (I hope) familiar.

*

The "multiple r�le accounts" model. Think, basically, of how
Windows NT works. There's no superuser. Individual accounts have
have special flags assigned to them that mark them as capable of
specific, privileged, operations, such as giving away ownership of
files/directories, taking ownership of files/directories,
bypassing lack of 'x' permissions on directories, modifying any
part of the password database, creating new user tokens, and so forth.

There are, of course, several less common models, such as capabilities
and so forth. Linux, for example, looks like a "superuser" model but in
many ways nowadays is more like a "multiple r�le accounts" model, albeit
not completely. chown is in fact a case in point.

One of the things that you're missing is that there are two different
"appropriate privileges", here. The standard for chown has allowed for
several implementation choices:

*

The system uses the "superuser" model and only the superuser may
change ownerships of anything, and of course will always be able
to preserve set-ID flags.

*

The system uses the "superuser" model but is (in z/OS UNIX
terminology) a CHOWN.UNRESTRICTED system, where anybody can chown
their own files/directories willy-nilly. The "appropriate
privilege" for being able to preserve set-ID flags across chown is
usually still reserved to the superuser alone, to close the
obvious privilege escalation loophole.

*

The system uses the "multiple r�le accounts" model, and there are
two privileges that accounts can possess: ability to chown someone
else's files/directories, and ability to preserve set-ID flags
across chown. Who can do what, and in what combinations, depends
from which user accounts have which privileges, the policy for
which is set by humans, not by the system itself.

On Linux, the "appropriate privilege" for being able to change
ownerships of someone else's files/directories is a combination of
CAP_CHOWN and "unrestricted_chown" mount options; however the
"appropriate privilege" for being able to preserve set-ID flags is
reserved to the superuser alone and is not an account-possessable
privilege. So Linux has one foot in both camps, here.

Solaris is even more like a "multiple r�le accounts" model. The
PRIV_FILE_SETID privilege is the ability to preserve set-ID flags across
chown, as long as one is not chowning to UID 0 when one isn't UID 0.
The PRIV_FILE_CHOWN privilege is the ability to chown someone else's
files/directories, as long as that someone else, or the target UID, is
not UID 0. The PRIV_FILE_CHOWN_SELF privilege is the ability to give
away one's own ownership of a file/directory to someone else. And
there's a global configuration setting, rstchown, read at IPL time, that
enables PRIV_FILE_CHOWN_SELF for everyone if set to 0.

Interestingly, on Windows NT, both "appropriate privileges" are combined
into one: SeRestorePrivilege. This allows one both to write the owner
of a file/directory (i.e. change it to whatever owner one likes) and to
write the discretionary ACL and attributes of a file/directory (which
Cygwin, Interix, MK, and so forth will map to the POSIX set-ID flags).

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Dealing with different number of fields in a file
Next: Linuxrc and nash