[ale] Allow non-root user to chown file to other user?
Jeff Lightner
jlightner at water.com
Sat Nov 17 14:02:31 EST 2007
Thanks Mike - that's the most complete answer I've ever seen.
It answers my original question quite adequately.
-----Original Message-----
From: Michael H. Warfield [mailto:mhw at WittsEnd.com]
Sent: Friday, November 16, 2007 7:12 PM
To: Jeff Lightner
Cc: mhw at WittsEnd.com; Atlanta Linux Enthusiasts
Subject: RE: [ale] Allow non-root user to chown file to other user?
Ok...
Long answer. Maybe this will answer your question or at least
help you
solve your problem. Not all problems are solvable. Not a problems are
technical.
On Fri, 2007-11-16 at 11:06 -0500, Jeff Lightner wrote:
> An opinion no matter how much YOU agree with it is still an opinion
and
> therefore isn't "technical". That is my opinion.
Yes, well, and as a security expert, I tend to have strongly
held
opinions on matters when they impinge upon the security arena. I
especially don't like people using excuses for exercising bad habits and
creating bad implementations because they aren't (now, yet, think they
ever will be) using something where they think security (is, was, ever
will be) important. That's why your comment about an RFC was sublimely
amusing. If that behavior of chown ever did come up at a "modern" IETF
meeting, it never would get into an RFC in that form explicitly because
of the security issues. I've sat in on a few of those working groups
where people have gotten down right nasty over security (ok, ok, it's
the IETF, they don't need to get worked up over security to get down
right nasty, I know).
I run into lots of people who insist that they absolutely can
not solve
this problem or that problem without their favorite security hole (I
know of one group who insisted that they could only retrieve patient
data interstate, over the Internet, by using telnet - till they were
taught a lesson or two about HIPAA). If it doesn't work that way, you
just have to find another solution to your problem. Sometimes, you just
need to ask the right question and not try and predetermine the answer
to merely give you what you want and not what you need. Sometimes you
need to be creative and think outside the box and sometimes you need to
think seriously about your goal and not so much about how you think you
need to get there.
Be that as it may, the OpenGroup has also taken a position in
this
matter as well.
Reference: OpenGroup Standards, online publications, and
documentation...
http://www.opengroup.org/onlinepubs/009695399/functions/chown.html
(Note: this is on the chown() function call, not merely the
chown
command).
Relevant sections - Application Usage and Rational (under the
"informative" section)...
Exert:
====
APPLICATION USAGE
Although chown() can be used on some implementations by the file
owner to change the owner and group to any desired values, the
only portable use of this function is to change the group of a
file to the effective GID of the calling process or to a member
of its group set.
RATIONALE
System III and System V allow a user to give away files; that
is, the owner of a file may change its user ID to anything. This
is a serious problem for implementations that are intended to
meet government security regulations. Version 7 and 4.3 BSD
permit only the superuser to change the user ID of a file. Some
government agencies (usually not ones concerned directly with
security) find this limitation too confining. This volume of
IEEE Std 1003.1-2001 uses may to permit secure implementations
while not disallowing System V.
System III and System V allow the owner of a file to change the
group ID to anything. Version 7 permits only the superuser to
change the group ID of a file. 4.3 BSD permits the owner to
change the group ID of a file to its effective group ID or to
any of the groups in the list of supplementary group IDs, but to
no others.
The POSIX.1-1990 standard requires that the chown() function
invoked by a non-appropriate privileged process clear the
S_ISGID and the S_ISUID bits for regular files, and permits them
to be cleared for other types of files. This is so that changes
in accessibility do not accidentally cause files to become
security holes. Unfortunately, requiring these bits to be
cleared on non-executable data files also clears the mandatory
file locking bit (shared with S_ISGID), which is an extension on
many implementations (it first appeared in System V). These bits
should only be required to be cleared on regular files that have
one or more of their execute bits set.
===
As stated above... "the only portable use of this function is
to
change the group of a file to the effective GID of the calling process
or to a member of its group set." Linux has chosen to adhere to that
standard (yes, I realize the "portability" issue they are referring to
is the various implementations at the OS level, and this is the
portability of the library functions).
While that references POSIX.1-1990, there are further
restrictions and
clarifications associated with POSIX.1-2001.
As far as other flavors of Unix go, note the commentary about
the
difference between System III and System V vs Version 7 and 4.3 BSD.
It's not just a Linux thing and the OpenGroup documentation advise
against the looser implementation and explains why.
It may be possible to work around things with capabilities and
such,
but there's little incentive for any of us to do so, especially when the
standards recommendations say otherwise. If you want a "technical"
reason, meeting government security regulations also sounds like a very
good one to me. It's a design decision. The reasons are many but, at
the bottom, it's a design decision made in the face of potential
security issues and ease of meeting government security regulations.
Argue with it all you like, but it still boils down to "it's a design
decision".
Let's see... What does Unix.com have to say about it...
http://www.unix.com/tips-tutorials/19060-unix-file-permissions.html
===
chown -- Changing The File Owner
Originally, Unix allowed a file owner to give away a file. A file's
owner could change the owner to someone else. There was no way for a
non-root user to undo this operation. When Unix split into a
Berkeley/AT&T versions, the USG (Unix Support Group, part of AT&T)
versions of Unix tended to inherit this behavior. Meanwhile BSD
(Berkeley Software Distribution, part of University of California,
Berkeley) removed chown from non-root users. BSD had implemented disk
quotas which could limit how much disk space a user could have in a
filesystem. Naughty users could give away large files to sneek past the
quotas.
Today, it is not easy to say if a non-root can chown a file. Many
versions of Unix allow both behaviors. HP-UX has a setprivgroup facility
that can control whether or not members of a particular group can invoke
chown. Solaris has a global paramter rstchown which can be set to allow
global chown. Setting this parameter also disables a change-group
limitation described below (without affecting the SGID limitations
dexribed above. Recent Linux version have a CAP_CHOWN capability to
control this feature. You will need to consult your documentation for
other versions of Unix. And you will need to consult your System
Administrator to see how your particular system is configured.
The default with most OS's is for chown to be restricted to root only.
And there is a consensus that it should stay this way for security
considerations. If a non-root user does change the owner of a file and
any execute bit is on, the SUID and SGID bits must be cleared. This may
or may not happen with root.
===
I think that last paragraph says it nicely.
That article also references "CAP_CHOWN" to control that
facility on
Linux (that should only affect the "POSIX_CHOWN_RESTRICTED" behavior.
There is also the "CAP_FOWNER" capability, that's a little different in
behavior. You claim to have gone down the "capabilities" path but then
you don't explain why that doesn't solve your problem. Are you running
with a recent enough kernel? It does say "Recent Linux versions". Did
it not work at all or did you merely feel it wasn't convenient enough?
Particularly, you don't explain why it doesn't solve your
problem after
you explicitly have to mention the workarounds you have to apply in
Solaris (a global system variable - YUCK) and HP/UX. That SHOULD be the
answer to your question on Linux, if the other workarounds are the
answer on those other systems.
Lets see... Hmmm "man posixoptions":
===
--- - POSIX_CHOWN_RESTRICTED
If this option is in effect (as it always is under POSIX.1-2001)
then
only root may change the owner of a file, and non-root can only
set the
group of a file to one of the groups it belongs to. This
affects the
functions chown(), fchown().
===
Note: "If this option is in effect (as it always is under
POSIX.1-2001)".
Ok... There's another technical reason for you. POSIX.1-2001
compliance.
Looking at BSD (OpenBSD specifically) I don't see how to alter
that
behavior.
Have you tried using sucap to set the capabilities? It takes
some
headstanding. You'll need a script that will run as root under sudo
that invokes sucap with the real user-id and group-id with the CAP_CHOWN
capability and the chown command. That SHOULD work, using capabilities.
You can even wrap that in a shell wrapper, say sucapchown.sh, that calls
the sudo command. Sucap must run as root but you can then invoke a
command with a specific user id and group id (which sudo does pass to
you) and the capabilities (CAP_CHOWN) and the command to invoke.
You want another choice (and I've used this too), use ssh with
ssh keys
and restricted accounts limited to copying files based on the keys in
the authorized-keys file. If all you want to do is to copy a file from
one user account to another and transfer ownership, this will do it.
Works between systems, works within systems, can be nicely restricted,
easy as doing a "cp". Not nearly as convoluted as the sudo / sucap
backflip either.
Doesn't explain why the supplemental groups method won't do what
you
want to accomplish. Just chgrp a file into a supplemental group you are
both a member of in a shared directory with an appropriate group read or
read write permission and volia. Or, do "sg" to switch to that
supplimental group and copy it. What does changing the ownership buy
you that this doesn't? Is there something you are trying to preserve in
that group setting and permission that restricts you? This actually
gives you much MUCH finer grained control of what people can do.
Allowing arbitrary chowns from anyone to anyone is fraught with
headaches (although you can control that somewhat with the sudo / sucap
backflip trick - you can restrict who can use it). Supplemental groups
allows you to bind groups of id's together to allow interchange of
files. Through selective permission controls on directories you can
even allow one-way transfers where A can hand a file off to B but not
vice versa. All around, it's a superior solution in being superior
security, finer grained control, positive user control, and portable.
> As noted earlier I do not believe chown in and of itself is dangerous
> and if it were that dangerous then the major UNIX variants I've worked
> on would also prohibit it entirely rather than having a way to
configure
> it. That is also my opinion.
>
> You are as free to disagree with my opinions as I am with yours.
>
> Setting groups wouldn't solve the specific need I had. The reason I
did
> NOT post my "purpose" as I've mentioned several times is I was looking
> for a specific configuration tool and did NOT want to wade through the
> opinions of others as to whether I should use such a tool if it
existed.
> As noted I'd already done quite a bit of research trying to find the
> answer before posting so had already seen most of the comments others
> had without ever actually answering the question.
> I'm gathering that either such a tool does not exist for Linux or that
> no one on the list actually knows about it so would rather argue with
my
> opinion on the subject.
The tool is to work with the CAP_CHOWN capability but you
started out
by ruling that out without saying why.
> I did NOT come to the list and say "hey I'm looking for a hammer that
> can be used as a screwdriver" - My question was more like: "Craftsman
> makes tools and one of them is a ball peen hammer. SnapOn makes
tools
> too and I'm constrained to use their tools so would like to see if
they
> make a ball peen hammer as well." Telling me to use SnapOn's claw
> hammer because only a moron would use a ball peen hammer doesn't
really
> answer the question I asked but rather gives me your opinion.
Nah... It was more like "I want you to tell me how to drive
this screw
but don't give me anything about screwdrivers".
> Since
> I'd already seen enough comments indicating that there were people
that
> thought that I attempted to prevent those kind of comments.
And this is the direct result. Maybe you just discovered that
all
those provisos and don't this and don't that were singularly
counterproductive? Nothing is going to let you directly allow you to
use chown directly, short of diabling "POSIX_CHOWN_RESTRICTED" and
rebuild the entire kernel (I'll leave that as an intellectual exercise
for you to locate if you are that inclined).
The answer to your original question is that what you want can
be done
but not the way you want. There's no way to simply enable chown to work
the way you want, short of rebuilding the kernel. But the answer to
your problem was countered by your own restrictions. You literally
said, "don't give me the correct answer" when you said you didn't want
to hear about capabilties. That will do what those other options did on
the other operating systems. But it won't let you run chown without
some creative use of scripts and sudo. And supplemental groups remain
as a superior solution, based on all the information you've provided,
outside of some real restricted cases (where you need to preserve group
membership and permissions for other reasons).
Mike
> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
> Michael H. Warfield
> Sent: Friday, November 16, 2007 10:33 AM
> To: Atlanta Linux Enthusiasts
> Cc: mhw at WittsEnd.com
> Subject: RE: [ale] Allow non-root user to chown file to other user?
>
> On Fri, 2007-11-16 at 08:49 -0500, Jeff Lightner wrote:
> > I haven't seen any technical explanation as to "why" in any of the
> > posts.
>
> Strange... I thought I saw several comments on the technical
> reasons
> of why it is dangerous (quotas being one distinctive one). That
should
> be sufficient. The "technical" answer would be that people who
> recognize it as being dangerous have prohibited it. It use to be that
> you could also, on many Unix system, have SUID scripts. It was
decided
> to prohibit those as well, because of the danger. People complaining
> and asking "how do I create an SUID script" are in the same boat as
you
> are. It's prohibited by design due to the inherent risks and there
are
> better, safer, ways to accomplish your goals. That's the technical
long
> and short of it.
>
> > I have seen OPINIONS like yours. Is this discussed in an RFC
> > somewhere?
>
> This isn't a protocol and it's not under the perusal of the
> IETF, so
> why would it be discussed in an RFC.
>
> But... As long as you have brought up the topic of an RFC, the
> IETF
> now requires security assessments and statements of security impacts
in
> RFC's which it published. For that reason alone, the security issues
> mentioned by others as why it's a bad idea would be appropriate as
> technical security issues in an RFC. IOW... You wouldn't be allowed
it
> under and RFC because it's insecure.
>
> > ssh is an even more dangerous tool in the wrong hands...
>
> Point is, you don't need what you are asking. There are other,
> better,
> safer, ways to accomplish your goal.
>
> Mike
>
> > -----Original Message-----
> > From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
> > James P. Kinney III
> > Sent: Friday, November 16, 2007 8:11 AM
> > To: Atlanta Linux Enthusiasts
> > Subject: RE: [ale] Allow non-root user to chown file to other user?
> >
> > On Thu, 2007-11-15 at 14:44 -0500, Jeff Lightner wrote:
> >
> > > Again I am asking if there is a way to allow non-root users to
> simply
> > > use the "real" chown command directly. It just doesn't seem to me
> > that
> > > this shouldn't be something that is configurable somehow
especially
> > > given that it is configurable on at least two UNIX variants I'm
> > familiar
> > > with.
> > >
> > The short answer is no. The prior posts discuss why. chown is a
> > dangerous tool in the wrong hands.
> >
> > Furthermore, a user can't chown a file to themselves. Again, it
> violates
> > the security of the system.
> >
> > All ways I've seen to workaround this are cludges that involve sudo
> > and/or setuid root scripts.
> >
> > email is a great workaround!
> >
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 |
http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best
of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of
it!
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------
More information about the Ale
mailing list