Store the switch.py rootfs files somewhere else or remove their /etc/shadow files for security reasons.

[fpqc]

Hiya Roli, I found a kind of security flaw in the design of the distro switcher.

Suppose you have a no-goodnik on your bash install through ssh. Right now, if you've used the WSL-switcher, they can just go do

cd /mnt/c/Users/Username/AppData/Local/lxss

then if there is any other rootfs than the default one, say rootfs_ubuntu_xenial, they can just enter that with cd and read off of /etc/shadow.

Two possible solutions: One, regenerate/delete the /etc/passwd and /etc/shadow files in switch.py, or store the rootfs_distro_tag folders inside of %localappdata%\lxss\rootfs\sbin, since Microsoft protects viewing that from bash, and bash prevents non-root users from viewing it (because of the nature of sbin).

[fpqc]

Nevermind, Roli, there are bigger problems with protecting the shadowfile now since 14951:
microsoft/WSL#1240

[RoliSoft]

I was about to create a separate directory for rootfs-s and just set chown root:root chmod 000 on it, this way at least you would need root to go into the directory. However, interestingly, lxattrb doesn't work on these directories for some reason:

RoliSoft@ROLISOFT-PC ...arch-rootfs $ ls -la /etc/passwd
-rw-r--r-- 1 root root 1388 Oct 23 12:37 /etc/passwd
RoliSoft@ROLISOFT-PC ...arch-rootfs $ ls -la etc/passwd
-rwxrwxrwx 1 root root 782 Oct 23 01:53 etc/passwd
RoliSoft@ROLISOFT-PC ...arch-rootfs $ getfattr -d etc/passwd
# file: etc/passwd
user.lxattrb=0sAAABAKSBAAAAAAAAAAAAAAAAAACY95MnfKKbJyx0ySfs7QtYAAAAAOztC1gAAAAA7O0LWAAAAAA=

As you can see, the non-active etc/passwd has the correct attributes, but is still displayed with 777 permissions.

Created a file on my desktop from Windows, tried to set 000 on it, and all it did was set the read-only attribute on the file:

RoliSoft@ROLISOFT-PC ≈ $ ls -la asd.txt
-rwxrwxrwx 1 root root 1929 Apr  5  2016 asd.txt
RoliSoft@ROLISOFT-PC ≈ $ chmod 000 asd.txt
RoliSoft@ROLISOFT-PC ≈ $ ls -la asd.txt
-r-xr-xr-x 1 root root 1929 Apr  5  2016 asd.txt

I'll continue experimenting. Maybe I can do something using Windows permissions which would not allow WSL to go into that directory, yet my script can work with it freely, preferably without admin rights.

[RoliSoft]

As long as you are the owner of the folder (which you are, since it's under your AppData) you can grant or deny yourself permission, and that will also work under WSL:

> icacls rootfs_pritunl_archlinux_latest /deny RoliSoft:F
processed file: rootfs_pritunl_archlinux_latest
Successfully processed 1 files; Failed processing 0 files

> bash -c "ls -la /mnt/c/Users/RoliSoft/AppData/Local/lxss/rootfs_pritunl_archlinux_latest"
ls: cannot open directory '/mnt/c/Users/RoliSoft/AppData/Local/lxss/rootfs_pritunl_archlinux_latest': Permission denied

> icacls rootfs_pritunl_archlinux_latest /grant RoliSoft:F
processed file: rootfs_pritunl_archlinux_latest
Successfully processed 1 files; Failed processing 0 files

> bash -c "ls -la /mnt/c/Users/RoliSoft/AppData/Local/lxss/rootfs_pritunl_archlinux_latest"
total 76
drwxrwxrwx 2 root root     0 Oct 23 01:51 .
drwxrwxrwx 2 root root     0 Oct 24 21:47 ..
-rwxrwxrwx 1 root root    26 Oct 23 01:51 .switch_label
[...]

Unfortunately, under newer WSL which supports running Windows commands, you can just run the icacls.exe command yourself, and give yourself permissions again...

I don't think this issue can be solved on my end, other than just making sure the switcher will always sync the passwd/shadow, therefore overwriting any malicious changes.

[RoliSoft]

Alternatively, I could introduce an optional "elevated security" option, which requires the scripts to run under admin, and would change the ownership of the non-active rootfs folders to something other than the regular user, so you won't be able to use icacls under WSL.

But, you can run WSL as admin, (as Windows Admin, not root) at which point you can use icacls again.

[fpqc]

Yeah, force-syncing will work.