Caused by trivial use File::Copy; import in the script.
Thank you.
EDIT: We are now trying to make it strict. Most of the strict-compatibility issues have been fixed except access to hard drive smart attributes and /dev/mem.
are you sure that UID 1000 (your non-root user) has actual read permission for that file ? the hardware-observe interface grants already full access to that location but interfaces will indeed not change file or directory permissions (also, are you sure hardware-observe was actually connected when you ran the app ? it does not auto-connect).
Manual connection of hardware-observe and other interfaces fixes the problem partially. How to fix second problem with loading of Perl base Cwd.so module? What interface can I use for that?
The issue is to use Perl base Cwd.so module (and other modules) from outside the snap since I can’t ship whole Perl base distribution in the snap. I add shipped Perl modules to PERL5LIB in the snapcraft.yaml without the need to use any scripts: https://github.com/linuxhw/hw-probe/blob/master/snap/snapcraft.yaml
So does that mean the clasasic confinement request can be closed ? (or probably turned into an interface auto-connection request instead (i.e. auto-connecting hardware-observe seems to make some sense for it)
The standard AppArmor template includes the following to support Perl modules:
# for perl apps/services
#include <abstractions/perl>
/usr/bin/perl{,5*} ixr,
# AppArmor <2.12 doesn't have rules for perl-base, so add them here
/usr/lib/@{multiarch}/perl{,5,-base}/** r,
/usr/lib/@{multiarch}/perl{,5,-base}/[0-9]*/**.so* mr,
That last one is intended to allow executable mappings of .so modules. It doesn’t match /usr/lib/x86_64-linux-gnu/perl-base/auto/Cwd/Cwd.so though since auto doesn’t match [0-9]*. This seems like a bug in the security policy. @jdstrand: thoughts?
while there is no interface that grants direct disk access, these messages from snappy-debug are extremely strange given it tries to open libs that it should always be allowed to read … perhaps @jdstrand (who has already been summoned above but is at a sprint this week i think) has an idea here why it thinks you should not be able to read libc or libm
strict confinement cannot be used due to 3 remaining issues:
SMART attributes for hard drives cannot be collected for now. It’s very important for my current study: https://github.com/linuxhw/SMART
Perl base modules from /usr/lib/x86_64-linux-gnu/perl-base/auto/ are currently denied to load. This blocks execution of the program.
The tool is intended to collect hardware operability details and system logs from the outside system. If it runs in the strict mode then it always detects Ubuntu Core instead (from /etc/os-release). I need a way to get content of outer /etc/os-release somehow.
note that these perl modules might not exist in future core snaps, while (as @jamesh pointed out) currently a bug prevents you from using it, your snap should always ship all necessary bits in the snap anyway… there is no gurantee that perl-base will be in any future core snaps.
the system-observe interface provides access to /var/lib/snapd/hostfs/etc/os-release which is the host system os-release …
Regarding the SMART access, we probably need a new interface to provide this … this is up to @jdstrand to decide though …
I’ve included perl-base to the snap and now it works almost fine. So let’s make it strict with the hope to improve probes by smartctl and hdparm outputs someday: https://snapcraft.io/hw-probe
Can I request to auto-connect all required interfaces?
Most of the *-observe seem reasonable for this snap. Can you comment on the following:
why is physical-memory-observe required? This is quite an information leak
why is log-observe required?
why is kernel-module-control required? This granted device ownership to the snap?
why is raw-usb required?
why is home required?
Please give very specific details on the required accesses (eg, down to executed commands with arguments). I suspect there might be some improvements to existing interfaces…
why is kernel-module-control required? This granted device ownership to the snap?
I’ve tried this interface to get output of lsmod command. It’s used to check if kernel modules are successfully loaded for particular hardware devices (e.g. if nvidia module is loaded and used by other modules). I don’t need to load any modules.
why is raw-usb required?
This is needed to get output of lsusb -v command to avoid the following error:
Couldn't open device, some information will be missing
why is home required?
The tool saves system analysis report to the HOME directory. User can refer to the report in future in the case of a system failure. I’m thinking about replacing it to SNAP_USER_COMMON and removing this dangerous interface from the snap. Is SNAP_USER_COMMON cleared after removing the snap?
Also the log Xorg.0.log can be found in the $HOME/.local/share/xorg/ directory in several Ubuntu versions, but it’s a rare case.
hardware-observe + raw-usb vs hardware-observe lsusb diff:
No power consumption details
No Manufacturer names
Diff:
--- lsusb.orig 2018-09-25 08:25:28.491309180 +0300
+++ lsusb.new 2018-09-25 08:25:50.946069454 +0300
@@ -1,3 +1,6 @@
+Couldn't open device, some information will be missing
+Couldn't open device, some information will be missing
+
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Device Descriptor:
bLength 18
@@ -10,8 +13,8 @@
idVendor 0x80ee VirtualBox
idProduct 0x0021 USB Tablet
bcdDevice 1.00
- iManufacturer 1 VirtualBox
- iProduct 3 USB Tablet
+ iManufacturer 1
+ iProduct 3
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
@@ -54,8 +57,6 @@
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
-Device Status: 0x0000
- (Bus Powered)
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
@@ -69,9 +70,9 @@
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 4.15
- iManufacturer 3 Linux 4.15.0-34-generic ohci_hcd
- iProduct 2 OHCI PCI host controller
- iSerial 1 --
+ iManufacturer 3
+ iProduct 2
+ iSerial 1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
@@ -103,30 +104,4 @@
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
- bInterval 255
-Hub Descriptor:
- bLength 11
- bDescriptorType 41
- nNbrPorts 12
- wHubCharacteristic 0x0002
- No power switching (usb 1.0)
- Ganged overcurrent protection
- bPwrOn2PwrGood 0 * 2 milli seconds
- bHubContrCurrent 0 milli Ampere
- DeviceRemovable 0x00 0x00
- PortPwrCtrlMask 0xff 0xff
- Hub Port Status:
- Port 1: 0000.0103 power enable connect
- Port 2: 0000.0100 power
- Port 3: 0000.0100 power
- Port 4: 0000.0100 power
- Port 5: 0000.0100 power
- Port 6: 0000.0100 power
- Port 7: 0000.0100 power
- Port 8: 0000.0100 power
- Port 9: 0000.0100 power
- Port 10: 0000.0100 power
- Port 11: 0000.0100 power
- Port 12: 0000.0100 power
-Device Status: 0x0001
- Self Powered
\ No newline at end of file
+ bInterval 255
\ No newline at end of file
