Re: major changes if gnu/linux dominates the desktop and/or mobile market?

[Grant Taylor <gtaylor () tnetconsulting net>]

On 10/5/20 2:48 PM, Solar Designer wrote:
> Hi all,

Hi,

> As a moderator I approved all messages in this thread so far, but I 
> am unhappy about the quality of both Georgi's message and the replies.

Thank you ...

> This is a valid topic, but there's no room in it for trolling (that's 
> how Georgi's message came across, even if maybe unintentionally) nor 
> for responding only about the presumed trolling.  Just assume good 
> faith and post a response that's actually useful to others in here.

... for presuming good intent in the hopes of a constructive conversation.

> I'll try:

:-)

> I'd say yes, major security changes are needed.
>
> On the desktop, major Linux distributions (and by the way *BSDs 
> and Solaris are not very different in this respect, I think) when 
> used as single-user desktop systems lack security isolation between 
> applications of the user.

I agree that there is a lot of room for improvement here.  But -- like 
you say -- I don't think this is isolated to Linux by any stretch of the 
imagination.  Unless I'm sorely mistaken, just about every contemporary 
desktop, and possibly server, operating system only gets as granular as 
the user level.

> (And also between the user and root, due to the typical recommended 
> use of sudo from the user account.)

Please elaborate what you mean here?

Are you commenting on the use of sudo (vs other access control 
mechanisms) or the seemingly default recommendation to allow members of 
the sudo group run any and all commands via sudo?  E.g.:

   %group ALL=(ALL) NOPASSWD: ALL

I personally have found judicious use of sudo to be quite effective. 
Meaning give the DB Administrators access to the explicit commands that 
they need.  Likewise with the OS Administrators.  Backup Operators, yep, 
them too.  But each group only gets the commands that they need and 
can't run the commands for other groups without additional level of 
intervention.

I believe that sudo as a tool has a LOT of potential and that many 
people are only using a tiny fraction of what it can do.

> This kind of security isolation is something we have on Android, 
> but at the price of the user not having full access to (not entirely) 
> their device.  The user cannot even have e.g. a file manager app with 
> which they'd access all files of other apps.

I don't know anything about Android other than it made me mad the last 
time I tried to use it.

I have seen some recent references to user namespaces and sub-IDs.  I'm 
on the lookout for information to see if that might be a way to run 
different applications as their own sub-user-id and then behave 
similarly to how applications running as different users work.  Meaning 
that each application -> user ID would have it's own files and would 
then rely on being a member of another group to access other files.  All 
the while relying on file system permissions to protect other things.

Aside:  If you know of something that I should be reading, please point 
me towards it.

Have Firefox run as <username>-<firefox> and Evolution run as 
<username>-<evolution>.  Both user would appear as a different user than 
just <username> thereby enabling traditional user & group security 
models between applications run by the same user.

I don't know if I'm hallucinating or if something like this is possible, 
or even done somewhere that I'm not aware of.

> For typical desktop Linux users, realistically most security is 
> provided by the web browser, which these days at least uses a 
> sandbox, protecting the user's files and other apps from itself. 
> That's something the underlying systems tend to lack.

I'm grateful that the web browser does do sandboxing.  But I don't think 
that we should need to rely on it for as much security as we do. 
Presuming of course that fat applications are being used and we're not 
running /everything/ inside the web browser.

> Sure malware and social engineering are valid threats to keep in mind.

I don't see how the operating system / security infrastructure can be 
responsible for protecting people here.

I guess the OS could make changes in some manner that they can be rolled 
back and rely on behavioral monitoring to detect when such a roll back 
is necessary as the result of deletion / encryption / corruption of 
documents.

> It's also a good idea not to rely solely on the browser's built-in 
> authorization checks, but to limit its access to system resources 
> such as the microphone and camera.  Qubes OS does that.

I naively think that some of this can be controlled with traditional 
file system permissions on the relevant device files.  If your (sub)user 
is not in the group to access the microphone -- guess what -- you don't 
get access to it.  Further, your (repeated) attempt to do so can be 
treated as an indicator of compromise.  Rinse, later, and repeat for 
other devices / files.

> Now this is about the lack of security isolation between the users, 
> if there's more than one actual user on a system.  I also do think 
> this is very wrong and needs to change (and is an easy change, unlike 
> others I pointed out above).

Linux, being a Unix like operating system, has been pressed into uses 
that weren't imagined when the old user based security model was developed.

The idea that multiple users have accounts on the same system and 
leverage group membership to divide their personal files from their 
teams files from other teams files simply does not remotely match our 
current use of these systems.

> Relaxed file permissions like that may also further weaken some partial 
> sandboxes (when a service is running with its dedicated credentials, 
> but with retained filesystem access - such as because it needs that).

I want to agree with that.  But, with things ultimately running as the 
same user, then any subdivision therein is difficult to enforce.

> Then there are also plenty of other local security risks on typical 
> Linux distros, starting with risky data processing by apport and abrt. 
> Those would matter more if other issues I mentioned are addressed.
>
> I might be right or wrong or (most likely) both, but I hope this sets 
> the tone for constructive further discussion.

:-)



--
Grant. . . .
unix || die

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature