search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.87k stars 496 forks source link

/dev/i2c incorrect group permission for non-root user poses security issues and concern #5686

Open keypunch416 opened 2 years ago

keypunch416 commented 2 years ago

Creating a bug report/issue

Required Information

Additional Information (if applicable)

Steps to reproduce

  1. ls -ls /dev/i2c*
  2. id

Expected behaviour

0 crw------- 1 root spi 89, 0 Jul 23 21:14 /dev/i2c-0 0 crw------- 1 root spi 89, 1 Jul 23 21:14 /dev/i2c-1 0 crw------- 1 root spi 89, 2 Jul 23 21:14 /dev/i2c-2

.

Actual behaviour

0 crw------- 1 root root 89, 0 Jul 23 21:14 /dev/i2c-0 0 crw------- 1 root root 89, 1 Jul 23 21:14 /dev/i2c-1 0 crw------- 1 root root 89, 2 Jul 23 21:14 /dev/i2c-2 uid=1001(sbc) gid=1001(sbc) groups=1001(sbc)

Extra details

Joulinar commented 2 years ago

By default no root privileges are required to access I2C bus with Raspberry Pi OS.

Just as a side note. On the N2, we don't use RPi OS as base image. If I'm not mistaken, it should be Armbian. Therefore you can't compare it that way. On my RPi3B+, it looks as you expect. 

root@DietPi:~# ls -ls /dev/i2c*
0 crw-rw---- 1 root i2c 89, 1 Aug 12 11:42 /dev/i2c-1
root@DietPi:~#

Probably there is a difference how Armbian is handling 🤔

keypunch416 commented 2 years ago

I am very awareaware dietpi does no use any part of Raspberry Pi OS.

My reference to Raspberry Pi Os was to make point that the /dev/i2c do not require root access. I can advise that the 8.6.1 N2+ dietpi image was root:root for /dev/i2c. I do not have any dietpi on my RPi3B. I have Raspberry Pi OS on RPi3B, RPi2B, and RPi1B+ and all were able to access /dev/i2c* with no root privileges. It is possible that dietpi image used for your RPi3B+ has correct owner:group (root:spi), but the N2+ at least for V8.6.1 did not have the expected owner:group. I know as even using i2cdetect on N2+ required root access, i.e. sudo, to be able to run. Never has been case in the years and versions of Raspberry Pi OS I have used on the RPis I have. The goal is to replace a number of the RPis with N2+ and some may need the 8GB RAM of M1 even though I only run CLI on these SBCs.

I was not making any reference to Armbian. I have made any attempt to test Armbian on this issue.

The 8GB RAM many be needed to be able to handle multiple passes of 20,000,000 test records every 10 minutes if 4GB RAM is not enough, i.e. Open Source application files because not enough memory to process the records. Records are not in database, just .csv file that creates a bit less than 9,000,000 records every 24 hours at rate of 100 records a second. The multiple passes of the 26,000,000 records is because most of time the last 36 hours of data that is used will span at least 48 hours and often 72 hours of data as a new file of data is created every 24 hours. So at least 26,000,000 records needs to be in memory as raw data and then again as Open Source applications need to read that data in multiple times to process the different graphs that need to be created every 10 minutes.

keypunch416 commented 2 years ago

I have issue #5645 open with no resolution yet as I really need to use the proper ADC for the application. So I decided to used a very inferior ADC that is an I2C device. ADCs needed for this type of application are all SPI based as these ADCs that should be used only use SPI. I was never expecting that the application would need run with root access. It is not good security to have a 24/7/365 user application run as root 24/7/365.

Joulinar commented 2 years ago

Maybe we misunderstood. DietPi is not an own OS. It's a set of bash scripts on top of a base image. In case of RPi device, we use RPI OS as base. Therefore, setting for /dev/i2c* on my RPi3B+ is fitting your expectation as it's DietPi using RPi OS base image.

On the other side, the N2 you are running is using Armbian as base image and not RPi OS. And my guess is, that Armbian is managing these things differently.

Our dietpi imager is not doing anthing with these settings. We just create an image as is. @MichaIng pls correct me if I'm wrong.

keypunch416 commented 2 years ago

All I know is as a user one expected the basics, in this issue case, I2C, to be accessible like many are used to with Raspberry Pi OS. I did not know the dietpi RPi3 images were based on Raspberry Pi OS.

The point is in my opinion that the many many I2C devices that are used with SBCs do not require root access to run. This is for very good security reasons. In many instances those using these I2C devices are likewise running the applications 24/7/365. To have to run these applications 24/7/365 as root defeats the whole and very good security reasons for creating non-root user to do all that one wants to do with I2C as user and not as root, not to mention the data being created is also created as root so drives users to run as root and break all the best practices of Unix as result. I find it amazing that I would be first one to run into this issue, let alone report it.

I also think it is amazing how such basics of SBC are being missed.

Does the dietpi is only set of scripts mean this issue will just sit and not be resolved?

keypunch416 commented 2 years ago

I need to repeat and ensure clarity with I thought was already very clear. The RPi's I have referenced as using Raspberry Pi OS were using Raspberry Pi OS proper. I was not, nor have I used, the dietpi based Raspberry Pi OS on any of the RPis I have.

Joulinar commented 2 years ago

I did not tell you would use DietPi on your RPi SBC. It was just a reference to our RPi SBC image which is based on RPI OS. Therefore, our image for RPi SBC is behaving same as a native RPI OS image.

On the other hand side, we have the N2, which is running a complete different image and should not be compared with RPi OS. Because it is based on Armbian. You could check how native Armbian is bahaving on your N2.

@MichaIng pls could you have a look. thx

keypunch416 commented 2 years ago

My point is and the issue raised is for the N2 image root access is being imposed by default for the N2 image. I am comparing basic functionality and security reasons why such functionality of RPi vs N2 is different and poses security risks with respect to N2/N2+ image. It is like saying because a car has brakes that truck should not have brakes, or some cars have windows and some cars do not have windows as reason to compare different cars for basic functionality to ensure locked car is not simple to break into. The statement that cannot compare a RPi image to N2 image does not make sense for security reasons as noted previously and subject of issue not to mention the Linux Kernel is being used for both the RPi and N2 image.

I do not have time to go about testing different images, such as the Armbian image, dietpi RPi3B image, et al. I am having enough challenges with outstanding issues such as "Unable to enable SPI /dev/spidev0.0" #5645 and "Odriod N2+ Does not Boot from eMMC" #5639 in addition to this issue that in essence makes the N2+s I purchased paperweights.

Given that it has been stated that dietpi is just scripts then it would make sense that testing Armbian would be waste of time. It also likely suggests those using the N2/N2+ are using as desktop, cluster, or such where in essence all they are using is USB and not using the GPIO.

MichaIng commented 2 years ago

This usually needs to be done manually, e.g. via udev rules:

echo -e 'SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"\nSUBSYSTEM=="spidev", GROUP="spi", MODE="0660"' > /etc/udev/rules.d/99-i2c_spi_group.rules

It uses spi group for SPI and i2c group for I2C, which is what you want, I guess?

On Armbian it doesn't work OOTB either, does it? I found their bsp packages to ship related udev rules only for selected SBCs, e.g. those with RockChip SoCs, and only for I2C, not SPI. However, it seems reasonable to me to add those by default to our images, as least for those two where the subsystems always have the same name (AFAIK).

keypunch416 commented 2 years ago

I would think it makes good sense for these udev rules to be part of OOTB default not just for security reasons, but because it really should be same for all SBCs that have I2C or SPI non-root access. It should not be hit and miss for some SBCs and not other SBCs that have I2C and/or SPI. It should not have to be done by user manually. I would think makes sense for these rules to exist in base image, so if that means needs to be implemented in Armbian to be able to be in the dietpi image then I would think that is best approach.

Of course if SPI udev rule is defined then likewise SPI should have overlay device tree for respective SBC that user can add to the boot up configuration to enable SPI. Again this should for all SBCs with SPI, not just of course "Unable to enable SPI /dev/spidev0.0" #5645 issue I opened related to N2+ that still means I cannot use the N2+ boards I ordered to be used with costly SPI devices I already have and have developed code for over past 18 months.

MichaIng commented 2 years ago

so if that means needs to be implemented in Armbian to be able to be in the dietpi image then I would think that is best approach.

We can and would need to implement these rules ourselves via dietpi-installer.

Of course if SPI udev rule is defined then likewise SPI should have overlay device tree for respective SBC that user can add to the boot up configuration to enable SPI.

That however is a kernel feature which is outside of our control, since we do no own kernel builds. As discussed in the other issue, we might be able to find a working device tree overlay for individual SBCs, but there is no generic approach, sadly.

keypunch416 commented 2 years ago

I noted the SPI rule dependence such as for example "Unable to enable SPI /dev/spidev0.0" #5645 because unlike the rule to be implemented for I2C cannot be tested to confirm the SPI rule works for the intended purpose. One test that should be simple enough to use to test the I2C rule will be using i2cdetect as user and not root.