[Kernel-packages] [Bug 1864669] Re: overlayfs regression - internal getxattr operations without sepolicy checking

2020-09-01 Thread Launchpad Bug Tracker
This bug was fixed in the package linux-aws - 4.15.0-1080.84

---
linux-aws (4.15.0-1080.84) bionic; urgency=medium

  * bionic/linux-aws: 4.15.0-1080.84 -proposed tracker (LP: #1890686)

  * Bionic update: upstream stable patchset 2020-07-17 (LP: #1887990)
- [Config] aws: updateconfigs for EFI_CUSTOM_SSDT_OVERLAYS

  * Bionic update: upstream stable patchset 2020-07-24 (LP: #1888907)
- [Config] aws: updateconfigs for BLK_DEV_SR_VENDOR

  * Packaging resync (LP: #1786013)
- [Packaging] update helper scripts
- [Packaging] update update.conf

  * overlayfs regression - internal getxattr operations without sepolicy
checking (LP: #1864669)
- SAUCE: overlayfs: internal getxattr operations without sepolicy checking

  [ Ubuntu: 4.15.0-114.115 ]

  * bionic/linux: 4.15.0-114.115 -proposed tracker (LP: #1891052)
  * ipsec: policy priority management is broken (LP: #1890796)
- xfrm: policy: match with both mark and mask on user interfaces

  [ Ubuntu: 4.15.0-113.114 ]

  * bionic/linux: 4.15.0-113.114 -proposed tracker (LP: #1890705)
  * Packaging resync (LP: #1786013)
- update dkms package versions
  * Reapply "usb: handle warm-reset port requests on hub resume" (LP: #1859873)
- usb: handle warm-reset port requests on hub resume
  * Bionic update: upstream stable patchset 2020-07-29 (LP: #1889474)
- gpio: arizona: handle pm_runtime_get_sync failure case
- gpio: arizona: put pm_runtime in case of failure
- pinctrl: amd: fix npins for uart0 in kerncz_groups
- mac80211: allow rx of mesh eapol frames with default rx key
- scsi: scsi_transport_spi: Fix function pointer check
- xtensa: fix __sync_fetch_and_{and,or}_4 declarations
- xtensa: update *pos in cpuinfo_op.next
- drivers/net/wan/lapbether: Fixed the value of hard_header_len
- net: sky2: initialize return of gm_phy_read
- drm/nouveau/i2c/g94-: increase NV_PMGR_DP_AUXCTL_TRANSACTREQ timeout
- irqdomain/treewide: Keep firmware node unconditionally allocated
- SUNRPC reverting d03727b248d0 ("NFSv4 fix CLOSE not waiting for direct IO
  compeletion")
- spi: spi-fsl-dspi: Exit the ISR with IRQ_NONE when it's not ours
- IB/umem: fix reference count leak in ib_umem_odp_get()
- uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to 
fix
  GDB regression
- ALSA: info: Drop WARN_ON() from buffer NULL sanity check
- ASoC: rt5670: Correct RT5670_LDO_SEL_MASK
- btrfs: fix double free on ulist after backref resolution failure
- btrfs: fix mount failure caused by race with umount
- btrfs: fix page leaks after failure to lock page for delalloc
- bnxt_en: Fix race when modifying pause settings.
- hippi: Fix a size used in a 'pci_free_consistent()' in an error handling
  path
- ax88172a: fix ax88172a_unbind() failures
- net: dp83640: fix SIOCSHWTSTAMP to update the struct with actual
  configuration
- drm: sun4i: hdmi: Fix inverted HPD result
- net: smc91x: Fix possible memory leak in smc_drv_probe()
- bonding: check error value of register_netdevice() immediately
- mlxsw: destroy workqueue when trap_register in mlxsw_emad_init
- ipvs: fix the connection sync failed in some cases
- i2c: rcar: always clear ICSAR to avoid side effects
- bonding: check return value of register_netdevice() in bond_newlink()
- serial: exar: Fix GPIO configuration for Sealevel cards based on XR17V35X
- scripts/decode_stacktrace: strip basepath from all paths
- HID: i2c-hid: add Mediacom FlexBook edge13 to descriptor override
- HID: apple: Disable Fn-key key-re-mapping on clone keyboards
- dmaengine: tegra210-adma: Fix runtime PM imbalance on error
- Input: add `SW_MACHINE_COVER`
- spi: mediatek: use correct SPI_CFG2_REG MACRO
- regmap: dev_get_regmap_match(): fix string comparison
- hwmon: (aspeed-pwm-tacho) Avoid possible buffer overflow
- dmaengine: ioat setting ioat timeout as module parameter
- Input: synaptics - enable InterTouch for ThinkPad X1E 1st gen
- usb: gadget: udc: gr_udc: fix memleak on error handling path in 
gr_ep_init()
- arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP
- x86: math-emu: Fix up 'cmp' insn for clang ias
- binder: Don't use mmput() from shrinker function.
- usb: xhci-mtk: fix the failure of bandwidth allocation
- usb: xhci: Fix ASM2142/ASM3142 DMA addressing
- Revert "cifs: Fix the target file was deleted when rename failed."
- staging: wlan-ng: properly check endpoint types
- staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift
- staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support
- staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift
- staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift
- serial: 8250: fix null-ptr-deref in serial8250_start_tx()
- serial: 8250_mtk: Fix high-speed baud rates 

[Kernel-packages] [Bug 1864669] Re: overlayfs regression - internal getxattr operations without sepolicy checking

2020-08-31 Thread Launchpad Bug Tracker
This bug was fixed in the package linux-aws - 5.4.0-1022.22

---
linux-aws (5.4.0-1022.22) focal; urgency=medium

  * focal/linux-aws: 5.4.0-1022.22 -proposed tracker (LP: #1890734)

  * Focal update: v5.4.51 upstream stable release (LP: #1886995)
- [Config] aws: updateconfigs for EFI_CUSTOM_SSDT_OVERLAYS

  * Focal update: v5.4.53 upstream stable release (LP: #1888560)
- [Config] aws: updateconfigs for BLK_DEV_SR_VENDOR

  * Focal update: v5.4.52 upstream stable release (LP: #1887853)
- [Packaging] aws: module intel-rapl-perf rename

  * Packaging resync (LP: #1786013)
- [Packaging] update variants
- [Packaging] update update.conf

  * add pvtime support for arm64 guests (LP: #1889282)
- arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit()
- arm64: errata: use arm_smccc_1_1_get_conduit()
- arm: spectre-v2: use arm_smccc_1_1_get_conduit()
- firmware/psci: use common SMCCC_CONDUIT_*
- firmware: arm_sdei: use common SMCCC_CONDUIT_*
- KVM: arm64: Document PV-time interface
- KVM: arm/arm64: Factor out hypercall handling from PSCI code
- KVM: arm64: Implement PV_TIME_FEATURES call
- KVM: Implement kvm_put_guest()
- KVM: arm64: Support stolen time reporting via shared structure
- KVM: Allow kvm_device_ops to be const
- KVM: arm64: Provide VCPU attributes for stolen time
- arm/arm64: Provide a wrapper for SMCCC 1.1 calls
- arm/arm64: Make use of the SMCCC 1.1 wrapper
- arm64: Retrieve stolen time as paravirtualized guest

  * overlayfs regression - internal getxattr operations without sepolicy
checking (LP: #1864669)
- SAUCE: overlayfs: internal getxattr operations without sepolicy checking

  [ Ubuntu: 5.4.0-44.48 ]

  * focal/linux: 5.4.0-44.48 -proposed tracker (LP: #1891049)
  * Packaging resync (LP: #1786013)
- [Packaging] update helper scripts
  * ipsec: policy priority management is broken (LP: #1890796)
- xfrm: policy: match with both mark and mask on user interfaces

  [ Ubuntu: 5.4.0-43.47 ]

  * focal/linux: 5.4.0-43.47 -proposed tracker (LP: #1890746)
  * Packaging resync (LP: #1786013)
- update dkms package versions
  * Devlink -  add RoCE disable kernel support  (LP: #1877270)
- devlink: Add new "enable_roce" generic device param
- net/mlx5: Document flow_steering_mode devlink param
- net/mlx5: Handle "enable_roce" devlink param
- IB/mlx5: Rename profile and init methods
- IB/mlx5: Load profile according to RoCE enablement state
- net/mlx5: Remove unneeded variable in mlx5_unload_one
- net/mlx5: Add devlink reload
- IB/mlx5: Do reverse sequence during device removal
  * msg_zerocopy.sh in net from ubuntu_kernel_selftests failed (LP: #1812620)
- selftests/net: relax cpu affinity requirement in msg_zerocopy test
  * Enlarge hisi_sec2 capability (LP: #1890222)
- Revert "UBUNTU: [Config] Disable hisi_sec2 temporarily"
- crypto: hisilicon - update SEC driver module parameter
  * Fix missing HDMI/DP Audio on an HP Desktop (LP: #1890441)
- ALSA: hda/hdmi: Add quirk to force connectivity
  * Fix IOMMU error on AMD Radeon Pro W5700 (LP: #1890306)
- PCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken
  * ASoC:amd:renoir:  the dmic can't record sound after suspend and resume
(LP: #1890220)
- SAUCE: ASoC: amd: renoir: restore two more registers during resume
  * No sound, Dummy output on Acer Swift 3 SF314-57G with Ice Lake core-i7  CPU
(LP: #1877757)
- ASoC: SOF: Intel: hda: fix generic hda codec support
  * Fix right speaker of HP laptop (LP: #1889375)
- SAUCE: hda/realtek: Fix right speaker of HP laptop
  * blk_update_request error when mount nvme partition (LP: #1872383)
- SAUCE: nvme-pci: prevent SK hynix PC400 from using Write Zeroes command
  * soc/amd/renoir: detect dmic from acpi table (LP: #1887734)
- ASoC: amd: add logic to check dmic hardware runtime
- ASoC: amd: add ACPI dependency check
- ASoC: amd: fixed kernel warnings
  * soc/amd/renoir: change the module name to make it work with ucm3
(LP: #1888166)
- AsoC: amd: add missing snd- module prefix to the acp3x-rn driver kernel
  module
- SAUCE: remove a kernel module since its name is changed
  * Focal update: v5.4.55 upstream stable release (LP: #1890343)
- AX.25: Fix out-of-bounds read in ax25_connect()
- AX.25: Prevent out-of-bounds read in ax25_sendmsg()
- dev: Defer free of skbs in flush_backlog
- drivers/net/wan/x25_asy: Fix to make it work
- ip6_gre: fix null-ptr-deref in ip6gre_init_net()
- net-sysfs: add a newline when printing 'tx_timeout' by sysfs
- net: udp: Fix wrong clean up for IS_UDPLITE macro
- qrtr: orphan socket in qrtr_release()
- rtnetlink: Fix memory(net_device) leak when ->newlink fails
- rxrpc: Fix sendmsg() returning EPIPE due to recvmsg() returning ENODATA
- tcp: allow at most one TLP probe per flight
- AX.25: Prevent integer overflows in connect and sendmsg
- 

[Kernel-packages] [Bug 1864669] Re: overlayfs regression - internal getxattr operations without sepolicy checking

2020-08-03 Thread Kelsey Margarete Skunberg
** Changed in: linux-aws (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1864669

Title:
  overlayfs regression - internal getxattr operations without sepolicy
  checking

Status in linux-aws package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  Fix Released
Status in linux-azure-4.15 package in Ubuntu:
  Invalid
Status in linux-aws source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux-azure-4.15 source package in Xenial:
  Invalid
Status in linux-aws source package in Bionic:
  Fix Committed
Status in linux-azure source package in Bionic:
  Fix Committed
Status in linux-azure-4.15 source package in Bionic:
  Fix Released
Status in linux-aws source package in Eoan:
  Fix Committed
Status in linux-azure source package in Eoan:
  Fix Released
Status in linux-azure-4.15 source package in Eoan:
  Invalid
Status in linux-aws source package in Focal:
  Fix Committed
Status in linux-azure source package in Focal:
  Fix Released
Status in linux-azure-4.15 source package in Focal:
  Invalid

Bug description:
  Bug description and repro:

  Run the following commands on host instances:

  Prepare the overlayfs directories:
  $ cd /tmp
  $ mkdir -p base/dir1/dir2 upper olwork merged
  $ touch base/dir1/dir2/file
  $ chown -R 10:10 base upper olwork merged

  Verify that the directory is owned by user 10:
  $ ls -al merged/ 
  total 8
  drwxr-xr-x  2 10 10 4096 Nov  1 07:08 .
  drwxrwxrwt 16 root   root   4096 Nov  1 07:08 ..

  We use lxc-usernsexec to start a new shell as user 10.
  $ lxc-usernsexec -m b:0:10:1 -- /bin/bash
  $$ ls -al merged/
  total 8
  drwxr-xr-x  2 root   root4096 Nov  1 07:08 .
  drwxrwxrwt 16 nobody nogroup 4096 Nov  1 07:08 ..

  Notice that the ownership of . and .. has changed because the new shell is 
running as the remapped user.
  Now, mount the overlayfs as an unprivileged user in the new shell. This is 
the key to trigger the bug.
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2/file 
  -rw-r--r-- 1 root root 0 Nov  1 07:09 merged/dir1/dir2/file

  We can see the file in the base layer from the mount directory. Now trigger 
the bug:
  $$ rm -rf merged/dir1/dir2/
  $$ mkdir merged/dir1/dir2
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 2 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..

  File does not show up in the newly created dir2 as expected. But it will 
reappear after we remount the filesystem (or any other means that might evict 
the cached dentry, such as attempt to delete the parent directory):
  $$ umount merged
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..
  -rw-r--r-- 1 root root0 Nov  1 07:09 file
  $$ exit
  $

  This is a recent kernel regression. I tried the above step on an old
  kernel (4.4.0-1072-aws) but cannot reproduce.


  I looked up linux source code and figured out where the "regression" is 
coming from. The issue lies in how overlayfs checks the "opaque" flag from the 
underlying upper-level filesystem. It checks the "trusted.overlay.opaque" 
extended attribute to decide whether to hide the directory content from the 
lower level. The logic are different in 4.4 and 4.15 kernel.
  In 4.4: https://elixir.bootlin.com/linux/v4.4/source/fs/overlayfs/super.c#L255
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
int res;
char val;
struct inode *inode = dentry->d_inode;

if (!S_ISDIR(inode->i_mode) || !inode->i_op->getxattr)
return false;

res = inode->i_op->getxattr(dentry, OVL_XATTR_OPAQUE, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  In 4.15: 
https://elixir.bootlin.com/linux/v4.15/source/fs/overlayfs/util.c#L349
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
return ovl_check_dir_xattr(dentry, OVL_XATTR_OPAQUE);
  }

  bool ovl_check_dir_xattr(struct dentry *dentry, const char *name)
  {
int res;
char val;

if (!d_is_dir(dentry))
return false;

res = vfs_getxattr(dentry, name, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  The 4.4 version simply uses the internal i_node callback 
inode->i_op->getxattr from the host filesystem, which doesn't perform any 
permission check. While the 4.15 version calls the VFS interface vfs_getxattr 
that performs bunch of permission checks before the calling the internal 
insecure callback __vfs_getxattr:
  See 

[Kernel-packages] [Bug 1864669] Re: overlayfs regression - internal getxattr operations without sepolicy checking

2020-07-30 Thread Kelsey Margarete Skunberg
** Changed in: linux-aws (Ubuntu Bionic)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1864669

Title:
  overlayfs regression - internal getxattr operations without sepolicy
  checking

Status in linux-aws package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  Fix Released
Status in linux-azure-4.15 package in Ubuntu:
  Invalid
Status in linux-aws source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux-azure-4.15 source package in Xenial:
  Invalid
Status in linux-aws source package in Bionic:
  Fix Committed
Status in linux-azure source package in Bionic:
  Fix Committed
Status in linux-azure-4.15 source package in Bionic:
  Fix Released
Status in linux-aws source package in Eoan:
  Fix Committed
Status in linux-azure source package in Eoan:
  Fix Released
Status in linux-azure-4.15 source package in Eoan:
  Invalid
Status in linux-aws source package in Focal:
  In Progress
Status in linux-azure source package in Focal:
  Fix Released
Status in linux-azure-4.15 source package in Focal:
  Invalid

Bug description:
  Bug description and repro:

  Run the following commands on host instances:

  Prepare the overlayfs directories:
  $ cd /tmp
  $ mkdir -p base/dir1/dir2 upper olwork merged
  $ touch base/dir1/dir2/file
  $ chown -R 10:10 base upper olwork merged

  Verify that the directory is owned by user 10:
  $ ls -al merged/ 
  total 8
  drwxr-xr-x  2 10 10 4096 Nov  1 07:08 .
  drwxrwxrwt 16 root   root   4096 Nov  1 07:08 ..

  We use lxc-usernsexec to start a new shell as user 10.
  $ lxc-usernsexec -m b:0:10:1 -- /bin/bash
  $$ ls -al merged/
  total 8
  drwxr-xr-x  2 root   root4096 Nov  1 07:08 .
  drwxrwxrwt 16 nobody nogroup 4096 Nov  1 07:08 ..

  Notice that the ownership of . and .. has changed because the new shell is 
running as the remapped user.
  Now, mount the overlayfs as an unprivileged user in the new shell. This is 
the key to trigger the bug.
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2/file 
  -rw-r--r-- 1 root root 0 Nov  1 07:09 merged/dir1/dir2/file

  We can see the file in the base layer from the mount directory. Now trigger 
the bug:
  $$ rm -rf merged/dir1/dir2/
  $$ mkdir merged/dir1/dir2
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 2 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..

  File does not show up in the newly created dir2 as expected. But it will 
reappear after we remount the filesystem (or any other means that might evict 
the cached dentry, such as attempt to delete the parent directory):
  $$ umount merged
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..
  -rw-r--r-- 1 root root0 Nov  1 07:09 file
  $$ exit
  $

  This is a recent kernel regression. I tried the above step on an old
  kernel (4.4.0-1072-aws) but cannot reproduce.


  I looked up linux source code and figured out where the "regression" is 
coming from. The issue lies in how overlayfs checks the "opaque" flag from the 
underlying upper-level filesystem. It checks the "trusted.overlay.opaque" 
extended attribute to decide whether to hide the directory content from the 
lower level. The logic are different in 4.4 and 4.15 kernel.
  In 4.4: https://elixir.bootlin.com/linux/v4.4/source/fs/overlayfs/super.c#L255
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
int res;
char val;
struct inode *inode = dentry->d_inode;

if (!S_ISDIR(inode->i_mode) || !inode->i_op->getxattr)
return false;

res = inode->i_op->getxattr(dentry, OVL_XATTR_OPAQUE, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  In 4.15: 
https://elixir.bootlin.com/linux/v4.15/source/fs/overlayfs/util.c#L349
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
return ovl_check_dir_xattr(dentry, OVL_XATTR_OPAQUE);
  }

  bool ovl_check_dir_xattr(struct dentry *dentry, const char *name)
  {
int res;
char val;

if (!d_is_dir(dentry))
return false;

res = vfs_getxattr(dentry, name, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  The 4.4 version simply uses the internal i_node callback 
inode->i_op->getxattr from the host filesystem, which doesn't perform any 
permission check. While the 4.15 version calls the VFS interface vfs_getxattr 
that performs bunch of permission checks before the calling the internal 
insecure callback __vfs_getxattr:
  See 

[Kernel-packages] [Bug 1864669] Re: overlayfs regression - internal getxattr operations without sepolicy checking

2020-07-22 Thread Kelsey Margarete Skunberg
** Changed in: linux-aws (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1864669

Title:
  overlayfs regression - internal getxattr operations without sepolicy
  checking

Status in linux-aws package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  Fix Released
Status in linux-azure-4.15 package in Ubuntu:
  Invalid
Status in linux-aws source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux-azure-4.15 source package in Xenial:
  Invalid
Status in linux-aws source package in Bionic:
  In Progress
Status in linux-azure source package in Bionic:
  Fix Committed
Status in linux-azure-4.15 source package in Bionic:
  Fix Released
Status in linux-aws source package in Eoan:
  Fix Committed
Status in linux-azure source package in Eoan:
  Fix Released
Status in linux-azure-4.15 source package in Eoan:
  Invalid
Status in linux-aws source package in Focal:
  In Progress
Status in linux-azure source package in Focal:
  Fix Released
Status in linux-azure-4.15 source package in Focal:
  Invalid

Bug description:
  Bug description and repro:

  Run the following commands on host instances:

  Prepare the overlayfs directories:
  $ cd /tmp
  $ mkdir -p base/dir1/dir2 upper olwork merged
  $ touch base/dir1/dir2/file
  $ chown -R 10:10 base upper olwork merged

  Verify that the directory is owned by user 10:
  $ ls -al merged/ 
  total 8
  drwxr-xr-x  2 10 10 4096 Nov  1 07:08 .
  drwxrwxrwt 16 root   root   4096 Nov  1 07:08 ..

  We use lxc-usernsexec to start a new shell as user 10.
  $ lxc-usernsexec -m b:0:10:1 -- /bin/bash
  $$ ls -al merged/
  total 8
  drwxr-xr-x  2 root   root4096 Nov  1 07:08 .
  drwxrwxrwt 16 nobody nogroup 4096 Nov  1 07:08 ..

  Notice that the ownership of . and .. has changed because the new shell is 
running as the remapped user.
  Now, mount the overlayfs as an unprivileged user in the new shell. This is 
the key to trigger the bug.
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2/file 
  -rw-r--r-- 1 root root 0 Nov  1 07:09 merged/dir1/dir2/file

  We can see the file in the base layer from the mount directory. Now trigger 
the bug:
  $$ rm -rf merged/dir1/dir2/
  $$ mkdir merged/dir1/dir2
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 2 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..

  File does not show up in the newly created dir2 as expected. But it will 
reappear after we remount the filesystem (or any other means that might evict 
the cached dentry, such as attempt to delete the parent directory):
  $$ umount merged
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..
  -rw-r--r-- 1 root root0 Nov  1 07:09 file
  $$ exit
  $

  This is a recent kernel regression. I tried the above step on an old
  kernel (4.4.0-1072-aws) but cannot reproduce.


  I looked up linux source code and figured out where the "regression" is 
coming from. The issue lies in how overlayfs checks the "opaque" flag from the 
underlying upper-level filesystem. It checks the "trusted.overlay.opaque" 
extended attribute to decide whether to hide the directory content from the 
lower level. The logic are different in 4.4 and 4.15 kernel.
  In 4.4: https://elixir.bootlin.com/linux/v4.4/source/fs/overlayfs/super.c#L255
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
int res;
char val;
struct inode *inode = dentry->d_inode;

if (!S_ISDIR(inode->i_mode) || !inode->i_op->getxattr)
return false;

res = inode->i_op->getxattr(dentry, OVL_XATTR_OPAQUE, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  In 4.15: 
https://elixir.bootlin.com/linux/v4.15/source/fs/overlayfs/util.c#L349
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
return ovl_check_dir_xattr(dentry, OVL_XATTR_OPAQUE);
  }

  bool ovl_check_dir_xattr(struct dentry *dentry, const char *name)
  {
int res;
char val;

if (!d_is_dir(dentry))
return false;

res = vfs_getxattr(dentry, name, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  The 4.4 version simply uses the internal i_node callback 
inode->i_op->getxattr from the host filesystem, which doesn't perform any 
permission check. While the 4.15 version calls the VFS interface vfs_getxattr 
that performs bunch of permission checks before the calling the internal 
insecure callback __vfs_getxattr:
  See 

[Kernel-packages] [Bug 1864669] Re: overlayfs regression - internal getxattr operations without sepolicy checking

2020-07-20 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: linux-aws (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1864669

Title:
  overlayfs regression - internal getxattr operations without sepolicy
  checking

Status in linux-aws package in Ubuntu:
  Confirmed
Status in linux-azure package in Ubuntu:
  Fix Released
Status in linux-azure-4.15 package in Ubuntu:
  Invalid
Status in linux-aws source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux-azure-4.15 source package in Xenial:
  Invalid
Status in linux-aws source package in Bionic:
  In Progress
Status in linux-azure source package in Bionic:
  Fix Committed
Status in linux-azure-4.15 source package in Bionic:
  Fix Released
Status in linux-aws source package in Eoan:
  In Progress
Status in linux-azure source package in Eoan:
  Fix Released
Status in linux-azure-4.15 source package in Eoan:
  Invalid
Status in linux-aws source package in Focal:
  In Progress
Status in linux-azure source package in Focal:
  Fix Released
Status in linux-azure-4.15 source package in Focal:
  Invalid

Bug description:
  Bug description and repro:

  Run the following commands on host instances:

  Prepare the overlayfs directories:
  $ cd /tmp
  $ mkdir -p base/dir1/dir2 upper olwork merged
  $ touch base/dir1/dir2/file
  $ chown -R 10:10 base upper olwork merged

  Verify that the directory is owned by user 10:
  $ ls -al merged/ 
  total 8
  drwxr-xr-x  2 10 10 4096 Nov  1 07:08 .
  drwxrwxrwt 16 root   root   4096 Nov  1 07:08 ..

  We use lxc-usernsexec to start a new shell as user 10.
  $ lxc-usernsexec -m b:0:10:1 -- /bin/bash
  $$ ls -al merged/
  total 8
  drwxr-xr-x  2 root   root4096 Nov  1 07:08 .
  drwxrwxrwt 16 nobody nogroup 4096 Nov  1 07:08 ..

  Notice that the ownership of . and .. has changed because the new shell is 
running as the remapped user.
  Now, mount the overlayfs as an unprivileged user in the new shell. This is 
the key to trigger the bug.
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2/file 
  -rw-r--r-- 1 root root 0 Nov  1 07:09 merged/dir1/dir2/file

  We can see the file in the base layer from the mount directory. Now trigger 
the bug:
  $$ rm -rf merged/dir1/dir2/
  $$ mkdir merged/dir1/dir2
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 2 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..

  File does not show up in the newly created dir2 as expected. But it will 
reappear after we remount the filesystem (or any other means that might evict 
the cached dentry, such as attempt to delete the parent directory):
  $$ umount merged
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..
  -rw-r--r-- 1 root root0 Nov  1 07:09 file
  $$ exit
  $

  This is a recent kernel regression. I tried the above step on an old
  kernel (4.4.0-1072-aws) but cannot reproduce.


  I looked up linux source code and figured out where the "regression" is 
coming from. The issue lies in how overlayfs checks the "opaque" flag from the 
underlying upper-level filesystem. It checks the "trusted.overlay.opaque" 
extended attribute to decide whether to hide the directory content from the 
lower level. The logic are different in 4.4 and 4.15 kernel.
  In 4.4: https://elixir.bootlin.com/linux/v4.4/source/fs/overlayfs/super.c#L255
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
int res;
char val;
struct inode *inode = dentry->d_inode;

if (!S_ISDIR(inode->i_mode) || !inode->i_op->getxattr)
return false;

res = inode->i_op->getxattr(dentry, OVL_XATTR_OPAQUE, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  In 4.15: 
https://elixir.bootlin.com/linux/v4.15/source/fs/overlayfs/util.c#L349
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
return ovl_check_dir_xattr(dentry, OVL_XATTR_OPAQUE);
  }

  bool ovl_check_dir_xattr(struct dentry *dentry, const char *name)
  {
int res;
char val;

if (!d_is_dir(dentry))
return false;

res = vfs_getxattr(dentry, name, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  The 4.4 version simply uses the internal i_node callback 
inode->i_op->getxattr from the host filesystem, which doesn't perform any 
permission check. While the 4.15 version calls the VFS interface vfs_getxattr 
that performs bunch of permission checks before the calling the internal 
insecure callback __vfs_getxattr:
  

[Kernel-packages] [Bug 1864669] Re: overlayfs regression - internal getxattr operations without sepolicy checking

2020-07-09 Thread Marcelo Cerri
** Summary changed:

- [linux-azure] overlayfs regression - internal getxattr operations without 
sepolicy checking
+ overlayfs regression - internal getxattr operations without sepolicy checking

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-aws in Ubuntu.
https://bugs.launchpad.net/bugs/1864669

Title:
  overlayfs regression - internal getxattr operations without sepolicy
  checking

Status in linux-aws package in Ubuntu:
  New
Status in linux-azure package in Ubuntu:
  Fix Released
Status in linux-azure-4.15 package in Ubuntu:
  Invalid
Status in linux-aws source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux-azure-4.15 source package in Xenial:
  Invalid
Status in linux-aws source package in Bionic:
  In Progress
Status in linux-azure source package in Bionic:
  Fix Committed
Status in linux-azure-4.15 source package in Bionic:
  Fix Released
Status in linux-aws source package in Eoan:
  In Progress
Status in linux-azure source package in Eoan:
  Fix Released
Status in linux-azure-4.15 source package in Eoan:
  Invalid
Status in linux-aws source package in Focal:
  In Progress
Status in linux-azure source package in Focal:
  Fix Released
Status in linux-azure-4.15 source package in Focal:
  Invalid

Bug description:
  Bug description and repro:

  Run the following commands on host instances:

  Prepare the overlayfs directories:
  $ cd /tmp
  $ mkdir -p base/dir1/dir2 upper olwork merged
  $ touch base/dir1/dir2/file
  $ chown -R 10:10 base upper olwork merged

  Verify that the directory is owned by user 10:
  $ ls -al merged/ 
  total 8
  drwxr-xr-x  2 10 10 4096 Nov  1 07:08 .
  drwxrwxrwt 16 root   root   4096 Nov  1 07:08 ..

  We use lxc-usernsexec to start a new shell as user 10.
  $ lxc-usernsexec -m b:0:10:1 -- /bin/bash
  $$ ls -al merged/
  total 8
  drwxr-xr-x  2 root   root4096 Nov  1 07:08 .
  drwxrwxrwt 16 nobody nogroup 4096 Nov  1 07:08 ..

  Notice that the ownership of . and .. has changed because the new shell is 
running as the remapped user.
  Now, mount the overlayfs as an unprivileged user in the new shell. This is 
the key to trigger the bug.
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2/file 
  -rw-r--r-- 1 root root 0 Nov  1 07:09 merged/dir1/dir2/file

  We can see the file in the base layer from the mount directory. Now trigger 
the bug:
  $$ rm -rf merged/dir1/dir2/
  $$ mkdir merged/dir1/dir2
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 2 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..

  File does not show up in the newly created dir2 as expected. But it will 
reappear after we remount the filesystem (or any other means that might evict 
the cached dentry, such as attempt to delete the parent directory):
  $$ umount merged
  $$ mount -t overlay -o lowerdir=base,upperdir=upper,workdir=olwork none merged
  $$ ls -al merged/dir1/dir2
  total 12
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 .
  drwxr-xr-x 1 root root 4096 Nov  1 07:10 ..
  -rw-r--r-- 1 root root0 Nov  1 07:09 file
  $$ exit
  $

  This is a recent kernel regression. I tried the above step on an old
  kernel (4.4.0-1072-aws) but cannot reproduce.


  I looked up linux source code and figured out where the "regression" is 
coming from. The issue lies in how overlayfs checks the "opaque" flag from the 
underlying upper-level filesystem. It checks the "trusted.overlay.opaque" 
extended attribute to decide whether to hide the directory content from the 
lower level. The logic are different in 4.4 and 4.15 kernel.
  In 4.4: https://elixir.bootlin.com/linux/v4.4/source/fs/overlayfs/super.c#L255
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
int res;
char val;
struct inode *inode = dentry->d_inode;

if (!S_ISDIR(inode->i_mode) || !inode->i_op->getxattr)
return false;

res = inode->i_op->getxattr(dentry, OVL_XATTR_OPAQUE, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  In 4.15: 
https://elixir.bootlin.com/linux/v4.15/source/fs/overlayfs/util.c#L349
  static bool ovl_is_opaquedir(struct dentry *dentry)
  {
return ovl_check_dir_xattr(dentry, OVL_XATTR_OPAQUE);
  }

  bool ovl_check_dir_xattr(struct dentry *dentry, const char *name)
  {
int res;
char val;

if (!d_is_dir(dentry))
return false;

res = vfs_getxattr(dentry, name, , 1);
if (res == 1 && val == 'y')
return true;

return false;
  }

  The 4.4 version simply uses the internal i_node callback 
inode->i_op->getxattr from the host filesystem, which doesn't perform any 
permission check. While the 4.15 version calls the VFS interface vfs_getxattr 
that performs bunch of permission checks before the