On 6/26/20 4:40 PM, Rich Freeman wrote:
On Fri, Jun 26, 2020 at 4:03 PM james <gar...@verizon.net> wrote:
So can some of the smarter (gentoo) folks illuminate how to totally
avoid groups and users, except for the minimum required, application
specific? For example like serial line tools, or outline a set of
tweaks/setting to avoid these altogether?
IMO if extra security is your goal then if anything you want to have
MORE use of users rather than less. Everything should be least
privilege, and usually that means having separate UIDs for everything,
and then layering on stuff like namespaces/SELinux/capabilities/etc on
top of that to further tailor things.
OK, that's a pathway forward, that I no longer believe in, though viable.
I think the days of systems design and implementation, that require a
default, multi-user, scenario, are arcane and subject to many attack
vectors. Granted many will and do disagree, and new pathways are rarely
well lighted in my experiences.
Of course the more config you have like this, the more there is to
audit. However, you also have to consider the failure mode. When you
have layers of security and some layer fails, chances are that the
failure still results in more containment than what you would have had
if you didn't build the layers in the first place.
Security Schema are many and all are under attack. Most of what I need
from a 'well behaved' collective of microprocessors and microcontrollers
are in-house and need little (data) from the outside. The need to share
outside is nice, but can be limited, dynamically for a wide variety of
reason. The deep desire to share, in part-and-parcel, is to be human.
For me, as a christian, its far deeper of a need, but that on me. Quick
and automated shut-off, is a concept I like very, very much.
Currently, the need to be able to "snap my fingers" and instantly
isolate, is mostly prevented because our USA government forces chip
manufacturers to put "bullshit and backdoors" into most all processors
and controllers. That shit has to STOP. They, including our F. Feds do
not have that right. If we do not fix this, SATAN gets control; hence
the end-times are upon us, like a thief in the night. That's my belief
and I know many that think it is too late, to fix. the first step is to
have 100% of critical systems components manufactured in the USA. Each
country can and should do their own thing. Leaders have now realized,
letting folks that rule the large corporations, "have it their way" has
landed up in a pile of problems.
Now, one thing that would result in fewer UIDs is installing less
stuff. Maybe that is what you're getting at, and of course reducing
the attack surface is a good thing. However, keep in mind that a UID
in /etc/passwd doesn't actually do anything if no process runs with
that UID - it is just a line in a text file. So, having a uucp group
when no processes have access to it doesn't really cause issues.
unless the remotes can inject into that causal hardware relationship and
exploit it? Who knows what lurks in them micro-codes of silicon these
days.... much of the hardware has hidden Rf channels, well hidden and it
requires quite expensive systems that the semiconductor companies
provide, mostly to governments, on a use-to-be limited basis. That's why
the USA is forcing AMD to bring 7-nm manufacturing to US soil, so they
are under USA rule-sets. Makes the Mafia look like choir boys......
here's one publicized:
https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/
and a bit deeper:
https://freetechsforum.com/minix-%E2%80%8Bintels-hidden-chip-operating-system/
Removing the group doesn't actually make things more secure, because
processes can use a gid even if it doesn't exist in /etc/groups.
Effectively any POSIX system has every uid/gid available even if there
is no /etc/passwd at all.
And that is coded into the parts of the kernel, we cannot eliminate?
Typical sploits?
Curiously, a bit deeper explanation?
I'm no expert at this stuff, but I am very interested to hear more, from
your perspective and experiences which you are comfortable sharing.
James
