[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51adb874-f967-5cf7-ffff-a2b871a5455b@spamtrap.tnetconsulting.net>
Date: Mon, 5 Oct 2020 15:53:26 -0600
From: Grant Taylor <gtaylor@...tconsulting.net>
To: oss-security@...ts.openwall.com
Subject: Re: major changes if gnu/linux dominates the desktop
and/or mobile market?
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
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4013 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
