Re: [PATCH v3 2/2] doc: warn about following symlinks recursively in chown/chgrp

[Michael Orlitzky]

On 01/08/2018 02:33 AM, Bernhard Voelker wrote:
> 
> * the patch adds the above to the macro choptL which is also used in
> node chcon.  Do you see the danger for chcon(1), too?

Sadly I don't know anything about SELinux. If a directory's context can
change whether or not the directory is writable by some user or group,
then I'd be suspicious of it.

(The fact that I changed the documentation of chcon was a mistake.)


> What about the attached?

Looks good to me, thanks!


> * IMO we should avoid mentioning internal processing strategies like
> "depth-first" - even guaranteeing depth-that would not avoid this
> issue: there is no reason to trust FROM-USER more than NEW-USER.
> Furthermore, not only these 2 users may be potential attackers in
> this scenario, but also others, depending on the mode bits of the
> involved files and directories, ACLs etc.

Fine with me, I need to think about this more. Something like the
following is true,

  * if you're loosening permissions w.r.t. some user/group, then
    you want to do it depth-first.

  * if you're tightening permissions w.r.t. some user/group, then
    you want to do it breadth-first.

The catch is that most operations do both at the same time. With chown,
for example, the new owner is almost always gaining permissions, and the
old owner is almost always losing them. The --from flag in chown helps
prevent the old owner from being sneaky, suggesting that depth-first
might be preferred there -- but that only works with chown.

In general, setfacl and chmod have the same problem but it's far less
clear how to avoid trouble. In particular, setfacl can add/subtract an
any number of permissions from any number of users/groups all at once.
In that kind of peril, heuristics like "operate in this order" don't
hold up. What you really want is to avoid doing anything in a directory
that is writable by someone you don't trust, which may or may not
include your own group members.

There is some precedent for that with things like,

 https://wiki.gentoo.org/wiki/Hardened/Grsecurity_Trusted_Path_Execution

and I think it would be interesting to see how many warnings my system
would throw out-of-the-box if I had it log whenever it followed a
symlink in a directory that is writable by someone other than myself
(the current process) or root.