| 1 |
On 30/01/2017 00:20, Michael Orlitzky wrote: |
| 2 |
> On 01/29/2017 05:07 PM, Alan McKinnon wrote: |
| 3 |
>> |
| 4 |
>> Sure it can be done, just don't chown -R <user> ~user. DO it the VERY |
| 5 |
>> long way round, file by file. Say you changed user "awesome" uid 300 to 400: |
| 6 |
>> |
| 7 |
>> find / -uid 300 -exec chown awesome {} \+ |
| 8 |
>> |
| 9 |
> |
| 10 |
> That will find symlinks created by UID 300, and chown will follow them |
| 11 |
> to give "awesome" ownership of the TARGET of the symlink; an easy root |
| 12 |
> exploit. If you are about to suggest "find -type f" or the |
| 13 |
> "--no-dereference" flag, then beware that chown will also follow |
| 14 |
> hardlinks and you're still screwed (albeit limited to one filesystem, |
| 15 |
> and on vanilla kernels). |
| 16 |
> |
| 17 |
> |
| 18 |
|
| 19 |
|
| 20 |
Good catch with symlinks. |
| 21 |
I don't see the point about hardlinks, they are just files with 2 |
| 22 |
dentries. When find gets to the second one it's already changed, so no |
| 23 |
problem. |
| 24 |
|
| 25 |
But I'm sure there are plenty edge case scenarios that make this whole |
| 26 |
process go awry, all pointing to the same conclusion: |
| 27 |
|
| 28 |
As a dev you shouldn't even try. Let the sysadmin deal with it. |
| 29 |
If a system user already has a UID different to the published standard, |
| 30 |
leave it alone, it's a human's problem |
| 31 |
|
| 32 |
-- |
| 33 |
Alan McKinnon |
| 34 |
alan.mckinnon@×××××.com |
Archives