RE: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface

[Mario.Limonciello]

Alan,

> -----Original Message-----
> From: Alan Cox [mailto:gnomes@xxxxxxxxxxxxxxxxxxx]
> Sent: Tuesday, October 10, 2017 2:41 PM
> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> Cc: gregkh@xxxxxxxxxxxxxxxxxxx; pali.rohar@xxxxxxxxx; dvhart@xxxxxxxxxxxxx;
> andy.shevchenko@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; platform-driver-
> x86@xxxxxxxxxxxxxxx; luto@xxxxxxxxxx; quasisec@xxxxxxxxxx;
> rjw@xxxxxxxxxxxxx; mjg59@xxxxxxxxxx; hch@xxxxxx
> Subject: Re: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce
> userspace interface
> 
> > There are some "write once" items that for the general purpose user that
> > won't brick a box, but should probably be blacklisted though.
> > I'll think this through some more.
> 
> I would strongly urge you to do whitelisting as it's good security. If
> you can divide the calls into something like this it fits the Linxu
> desktop model well:
> 
> Safe -> anyone can do it
> Console -> only console owner
> Superuser -> administrator level (things that can be irritating but
> don't persist a reboot)

I've added filtering in my most recent submission (v6).

I don't feel that any single one of these calls or pieces of data should
be accessible without root.  Furthermore discussion on the merits of different
levels is stepping into bikeshedding territory. 
If someone wants to bubble up things that they feel are safe to read or write 
as user, that can be the job of a daemon or other service to decide not the kernel.

> 
> Beyond that it's trickier - if you are an enterprise business then you
> don't for example want to allow someone with root on the system to
> subvert BIOS level settings they can't access.

This level of split is actually comprehended already by the BIOS itself.  When you
enable an administrative password on the BIOS, you aren't able to access (read
or write) a variety of settings without a security key (which requires some handshaking).

> 
> You need a minimum of CAP_SYS_RAWIO for anything that can (through bugs
> or design) subvert secure boot type stuff. It's also probably an
> appropriate check for 'anything goes' if you decide to have that
> category. CAP_SYS_RAWIO implies total power over the machine although
> with secureboot it's less clear.
> 
Secure boot can't programmatically be disabled from within OS.