Re: Unfortunate results from fake-super

2018-02-03 Thread Dave Gordon via rsync 
On 03/02/18 15:52, Dave Gordon via rsync wrote:
> On 03/02/18 13:20, Dave Gordon via rsync wrote:
>> When using fake-super mode in an rsync receiver, anything that's neither a
>> file nor a directory (e.g. devices, symlinks, etc) is converted into a file,
>> and properties such as original ownership, filetype, and permissions are
>> stored in a specific extended attribute.
>>
>> In the case of a symlink, the contents of the link are stored in a plain
>> file. The original mode of the symlink is normally irrelevant, because
>> (Linux) hosts ignore a symlink's mode and use that of the target instead.
>> But in fake-super mode, the original mode of the link itself (usually
>> 0120777) is used to set the permissions on the receiver's plain-file copy.
>>
>> This results in the copy being world-writable. If this plain file is altered
>> and then transferred back to the origin, the resulting symlink can point to
>> an arbitrary path, which leads to potential security issues.
>>
>> Example:
>>
>> This was first observed in version 3.1.1 on kubuntu, but is still the same
>> in version 3.1.3 as of 28 Jan 2018.
>> See also  Storing-ownership-device-nodes-without-root
>> 
>>   
>>
>> .Dave.
>>
>> --
>> Sent from: http://samba.2283325.n4.nabble.com/Samba-rsync-f2500462.html
>>
> 
> Hmm, the forum seems to have dropped the example (which was in 'raw'
> tags to preserve the formatting). Oh well, here it is ...
> 
> Example:
> 
> As regular user 'dg':
> dg$ mkdir src
> dg$ touch src/foo
> dg$ chmod 444 src/foo
> dg$ ln -s foo src/bar
> 
> Then as trusted (but unprivileged) user 'backup':
> backup$ id -a
> uid=1000(backup) gid=1000(backup) groups=1000(backup),100(users)
> backup$ umask
> 0022
> backup$ rsync -av src/ dst-nonsuper/
> backup$ rsync -av --fake-super src/ dst-fake-super/
> 
> Now as (untrusted) user 'guest':
> guest$ id -a
> uid=(guest) gid=(guest) groups=(guest)
> guest$ echo -n '/etc/shadow' > dst-nonsuper/bar
> bash: dst-nonsuper/bar: Permission denied
> guest$ echo -n '/etc/secret' > dst-fake-super/bar # allowed!!
> 
> And finally, as user 'dg', restore from the fake-super backup:
> dg$ rsync -av --fake-super -M--super dst-fake-super/ recovered/
> dg$ ls -laR */
> ./src:
> total 8
> drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
> lrwxrwxrwx 1 dg users3 Feb  3 11:59 bar -> foo
> -r--r--r-- 1 dg users0 Feb  3 11:59 foo
> 
> ./dst-nonsuper:
> total 8
> drwxr-xr-x 2 backup users 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
> lrwxrwxrwx 1 backup users3 Feb  3 11:59 bar -> foo
> -r--r--r-- 1 backup users0 Feb  3 11:59 foo
> 
> ./dst-fake-super:
> total 12
> drwxr-xr-x 2 backup backup 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users  4096 Feb  3 13:00 ..
> -rwxrwxrwx 1 backup backup   11 Feb  3 12:51 bar
> -rw-r--r-- 1 backup backup0 Feb  3 11:59 foo
> 
> ./recovered:
> total 8
> drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
> lrwxrwxrwx 1 dg users   11 Feb  3 12:51 bar -> /etc/secret
> -r--r--r-- 1 dg users0 Feb  3 11:59 foo
> 
> dg$ getfattr -d -R */
> 
> # file: dst-fake-super
> user.rsync.%stat="40755 0,0 32768:100"
> 
> # file: dst-fake-super/bar
> user.rsync.%stat="120777 0,0 32768:100"
> 
> # file: dst-fake-super/foo
> user.rsync.%stat="100444 0,0 32768:100"
> 
> .Dave.

In an attempt to avoid the above problem, one might try using a --chmod
option to ensure that the destination files are not world-writable (here
we use a rather silly chmod, just to make it more obvious what is -- and
isn't -- affected):


backup$ rsync -av src/ dst-nonsuper/
backup$ rsync -av --chmod=D0700,Fu=rx,g=,o=x src/ dst-chmod-501/
backup$ rsync -av --fake-super --chmod=D0700,Fu=rx,g=,o=x src/
dst-fake-chmod-501/
backup$ getfattr -d -R .
# file: dst-fake-chmod-501
user.rsync.%stat="40701 0,0 32768:100"

# file: dst-fake-chmod-501/bar
user.rsync.%stat="120777 0,0 32768:100"

# file: dst-fake-chmod-501/foo
user.rsync.%stat="100501 0,0 32768:100"

backup$ ll -R */
./src:
total 8
drwxr-xr-x 2 dg users 4096 Feb  3 11:59 ./
drwxrwxr-x 6 dg users 4096 Feb  3 17:16 ../
lrwxrwxrwx 1 dg users3 Feb  3 11:59 bar -> foo
-r--r--r-- 1 dg users0 Feb  3 11:59 foo

./dst-nonsuper:
total 8
drwxr-xr-x 2 backup users 4096 Feb  3 11:59 ./
drwxrwxr-x 6 dg users 4096 Feb  3 17:16 ../
lrwxrwxrwx 1 backup users3 Feb  3 11:59 bar -> foo
-r--r--r-- 1 backup users0 Feb  3 11:59 foo

./dst-chmod-501:
total 8
drwx-x 2 backup users 4096 Feb  3 11:59 ./
drwxrwxr-x 6 dg users 4096 Feb  3 17:16 ../
lrwxrwxrwx 1 backup users3 Feb  3 11:59 bar -> foo*
-r-x-x 1 backup users0 Feb  3 11:59 foo*

./dst-fake-chmod-501:
total 12
drwx-x 2 backup backup  4096 Feb  3 11:59 ./
drwxrwxr-x 6 dg users   4096 Feb  3 17:16 ../
-rwxrwxrwx 1 backup backup 3 Feb  3 11:59 bar*
-rwx-x 1

Re: Unfortunate results from fake-super

2018-02-03 Thread Dave Gordon via rsync 
On 03/02/18 13:20, Dave Gordon via rsync wrote:
> When using fake-super mode in an rsync receiver, anything that's neither a
> file nor a directory (e.g. devices, symlinks, etc) is converted into a file,
> and properties such as original ownership, filetype, and permissions are
> stored in a specific extended attribute.
> 
> In the case of a symlink, the contents of the link are stored in a plain
> file. The original mode of the symlink is normally irrelevant, because
> (Linux) hosts ignore a symlink's mode and use that of the target instead.
> But in fake-super mode, the original mode of the link itself (usually
> 0120777) is used to set the permissions on the receiver's plain-file copy.
> 
> This results in the copy being world-writable. If this plain file is altered
> and then transferred back to the origin, the resulting symlink can point to
> an arbitrary path, which leads to potential security issues.
> 
> Example:
> 
> This was first observed in version 3.1.1 on kubuntu, but is still the same
> in version 3.1.3 as of 28 Jan 2018.
> See also  Storing-ownership-device-nodes-without-root
> 
>   
> 
> .Dave.
> 
> --
> Sent from: http://samba.2283325.n4.nabble.com/Samba-rsync-f2500462.html
> 

Hmm, the forum seems to have dropped the example (which was in 'raw'
tags to preserve the formatting). Oh well, here it is ...

Example:

As regular user 'dg':
dg$ mkdir src
dg$ touch src/foo
dg$ chmod 444 src/foo
dg$ ln -s foo src/bar

Then as trusted (but unprivileged) user 'backup':
backup$ id -a
uid=1000(backup) gid=1000(backup) groups=1000(backup),100(users)
backup$ umask
0022
backup$ rsync -av src/ dst-nonsuper/
backup$ rsync -av --fake-super src/ dst-fake-super/

Now as (untrusted) user 'guest':
guest$ id -a
uid=(guest) gid=(guest) groups=(guest)
guest$ echo -n '/etc/shadow' > dst-nonsuper/bar
bash: dst-nonsuper/bar: Permission denied
guest$ echo -n '/etc/secret' > dst-fake-super/bar # allowed!!

And finally, as user 'dg', restore from the fake-super backup:
dg$ rsync -av --fake-super -M--super dst-fake-super/ recovered/
dg$ ls -laR */
./src:
total 8
drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
lrwxrwxrwx 1 dg users3 Feb  3 11:59 bar -> foo
-r--r--r-- 1 dg users0 Feb  3 11:59 foo

./dst-nonsuper:
total 8
drwxr-xr-x 2 backup users 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
lrwxrwxrwx 1 backup users3 Feb  3 11:59 bar -> foo
-r--r--r-- 1 backup users0 Feb  3 11:59 foo

./dst-fake-super:
total 12
drwxr-xr-x 2 backup backup 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users  4096 Feb  3 13:00 ..
-rwxrwxrwx 1 backup backup   11 Feb  3 12:51 bar
-rw-r--r-- 1 backup backup0 Feb  3 11:59 foo

./recovered:
total 8
drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
lrwxrwxrwx 1 dg users   11 Feb  3 12:51 bar -> /etc/shadow
-r--r--r-- 1 dg users0 Feb  3 11:59 foo

dg$ getfattr -d -R */

# file: dst-fake-super
user.rsync.%stat="40755 0,0 32768:100"

# file: dst-fake-super/bar
user.rsync.%stat="120777 0,0 32768:100"

# file: dst-fake-super/foo
user.rsync.%stat="100444 0,0 32768:100"

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Unfortunate results from fake-super

2018-02-03 Thread Dave Gordon via rsync 
When using fake-super mode in an rsync receiver, anything that's neither a
file nor a directory (e.g. devices, symlinks, etc) is converted into a file,
and properties such as original ownership, filetype, and permissions are
stored in a specific extended attribute.

In the case of a symlink, the contents of the link are stored in a plain
file. The original mode of the symlink is normally irrelevant, because
(Linux) hosts ignore a symlink's mode and use that of the target instead.
But in fake-super mode, the original mode of the link itself (usually
0120777) is used to set the permissions on the receiver's plain-file copy.

This results in the copy being world-writable. If this plain file is altered
and then transferred back to the origin, the resulting symlink can point to
an arbitrary path, which leads to potential security issues.

Example:

This was first observed in version 3.1.1 on kubuntu, but is still the same
in version 3.1.3 as of 28 Jan 2018.
See also  Storing-ownership-device-nodes-without-root

  

.Dave.



--
Sent from: http://samba.2283325.n4.nabble.com/Samba-rsync-f2500462.html

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html