[gentoo-user] What's with all these "acct-group" ebuilds recently?

[gentoo-user] What's with all these "acct-group" ebuilds recently?

[Walter Dnes]

  Inquiring minds want to know.  What exactly do they accomplish,
besides cluttering up a database somewhere?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Dale]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Walter Dnes wrote:
>   Inquiring minds want to know.  What exactly do they accomplish,
> besides cluttering up a database somewhere?
>


I found this:

https://wiki.gentoo.org/wiki/Categories_acct-group_and_acct-user

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 745 bytes --]

RE: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Sean O'Myers]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

How do unsubscrip from all

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Walter Dnes<mailto:waltdnes@waltdnes.org>
Sent: Saturday, June 20, 2020 12:05 AM
To: Gentoo Users List<mailto:gentoo-user@lists.gentoo.org>
Subject: [gentoo-user] What's with all these "acct-group" ebuilds recently?

  Inquiring minds want to know.  What exactly do they accomplish,
besides cluttering up a database somewhere?

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications


[-- Attachment #2: Type: text/html, Size: 2248 bytes --]

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Daniel Frey]

On 6/19/20 9:04 PM, Walter Dnes wrote:
>    Inquiring minds want to know.  What exactly do they accomplish,
> besides cluttering up a database somewhere?
> 

It's not the cluttering of databases that bother me, it's the creation 
of many ambiguous requests now. I went to emerge mythtv (I think) and 
now it says it's an ambiguous requests with *both* the group and user of 
the same name.

I must say I'm baffled that a proposal that would create so many 
ambiguous requests passed...

Dan

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Ralph Seichter]

* Daniel Frey:

> I went to emerge mythtv (I think) and now it says it's an ambiguous
> requests with *both* the group and user of the same name.

You need to emerge "media-tv/mythtv", not just "mythtv". Nothing
ambiguous about it.

Further reading: https://www.gentoo.org/glep/glep-0081.html

-Ralph

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Daniel Frey]

On 6/20/20 11:56 AM, Ralph Seichter wrote:
> * Daniel Frey:
> 
>> I went to emerge mythtv (I think) and now it says it's an ambiguous
>> requests with *both* the group and user of the same name.
> 
> You need to emerge "media-tv/mythtv", not just "mythtv". Nothing
> ambiguous about it.
> 
> Further reading: https://www.gentoo.org/glep/glep-0081.html
> 
> -Ralph
> 

You just pointed out the ambiguity.

Emerging a package solely by its name worked 99.9% of the time before 
this change.

Now new users get the fun of "Gee, which one is the one I actually 
want?" MythTV is a fairly clear one to figure out, but other packages 
aren't.

I understand the dependencies problem that they were trying to solve, 
but I don't think the way it was implemented is a great one.

Dan

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Michael Orlitzky]

On 2020-06-20 19:06, Daniel Frey wrote:
> 
> I understand the dependencies problem that they were trying to solve, 
> but I don't think the way it was implemented is a great one.
> 

This isn't a fundamental problem, it's your package manager being dumb.
File a bug; I can think of several band-aids for this, like adding a
flag to emerge that makes it prefer non-acct-* packages and then adding
that flag to EMERGE_DEFAULT_OPTS.

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Paul Colquhoun]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Sunday, June 21, 2020 9:25:38 A.M. AEST Michael Orlitzky wrote:
> On 2020-06-20 19:06, Daniel Frey wrote:
> > I understand the dependencies problem that they were trying to solve,
> > but I don't think the way it was implemented is a great one.
> 
> This isn't a fundamental problem, it's your package manager being dumb.
> File a bug; I can think of several band-aids for this, like adding a
> flag to emerge that makes it prefer non-acct-* packages and then adding
> that flag to EMERGE_DEFAULT_OPTS.


Or do a quick check to see if any of the packages are dependencies of one of the 
other packages, and prefer the one highest on the ladder.


-- 
Reverend Paul Colquhoun, ULC.     http://andor.dropbear.id.au/
  Asking for technical help in newsgroups?  Read this first:
     http://catb.org/~esr/faqs/smart-questions.html#intro


[-- Attachment #2: Type: text/html, Size: 3939 bytes --]

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Ralph Seichter]

* Daniel Frey:

> You just pointed out the ambiguity.

I did no such thing, and there is no ambiguity. There is only the
failure to specify a package's identifier ("atom").

> Emerging a package solely by its name worked 99.9% of the time before
> this change.

Perhaps for the packages you used; I have obviously not verified
that. Even if it was the case, it was not guaranteed to work that
way. Package atoms are, and have been, of the form CATEGORY/NAME, not
just NAME. Emerge also expects atoms, not names (as do package.mask,
package.use, etc.).

> Now new users get the fun of "Gee, which one is the one I actually
> want?" MythTV is a fairly clear one to figure out, but other packages
> aren't.

"New users" can rely on Gentoo utilities like "eix", "emerge --search"
or "equery". There's also https://packages.gentoo.org . Thus, I see no
problem.

-Ralph

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Rich Freeman]

On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey <djqfrey@gmail.com> wrote:
>
> You just pointed out the ambiguity.
>
> Emerging a package solely by its name worked 99.9% of the time before
> this change.
>
> Now new users get the fun of "Gee, which one is the one I actually
> want?" MythTV is a fairly clear one to figure out, but other packages
> aren't.

Honestly, your word of "ambiguity" was somewhat ambiguous.  I had no
idea what you were talking about in your original post.  :)

I think this is actually a fair criticism.  Not so much that it isn't
clear which one to install, but rather that this system does cause you
to have to use full cat/pkg atoms when previous pkg alone would have
worked.  There have always been packages where this is necessary, but
this has made this more common.

I don't think this was really something anybody thought of at the time
- perhaps somebody might have suggested a tweak at the time if it had
been.  As others have pointed out you could just tweak portage to
ignore the account category when expanding incomplete atoms to restore
the previous behavior.

In any case, as to why this system was devised just read:
https://www.gentoo.org/glep/glep-0081.html

It hasn't been communicated to users much because it tends to have
little impact on them.  Before packages just created accounts when
needed.  Now they pull in an account package that does it instead.  If
the user doesn't care to manage the uids/gids for various accounts
they don't need to worry about how this works.  If they do want to
manage these themselves they can either create those accounts manually
beforehand, or override these packages.  It is also much more obvious
when a new package is going to create additional accounts, so users
who care about such things can intervene before merging the packages.

Overall I'd say it is a net improvement.  It of course led to a whole
bunch of these packages being installed when the change was made, but
these would generally be no-ops for existing users.

-- 
Rich

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Daniel Frey]

On 6/20/20 6:21 PM, Rich Freeman wrote:
> On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey <djqfrey@gmail.com> wrote:
>>
>> You just pointed out the ambiguity.
>>
>> Emerging a package solely by its name worked 99.9% of the time before
>> this change.
>>
>> Now new users get the fun of "Gee, which one is the one I actually
>> want?" MythTV is a fairly clear one to figure out, but other packages
>> aren't.
> 
> Honestly, your word of "ambiguity" was somewhat ambiguous.  I had no
> idea what you were talking about in your original post.  :)
> 
> I think this is actually a fair criticism.  Not so much that it isn't
> clear which one to install, but rather that this system does cause you
> to have to use full cat/pkg atoms when previous pkg alone would have
> worked.  There have always been packages where this is necessary, but
> this has made this more common.
> 

Yes, I could've worded that better.

I would imagine that if someone asks to install something like mythtv or 
asterisk there's a 0% chance that they want to install a package that 
creates a user or group, they want the actual package itself.

I think that makes more sense.

I've been using gentoo since 2003/04? and I've only had to use the 
cat/package expression maybe twice... and I believe those packages were 
python or perl related.

It's more of a usability issue than anything.

The way that it now deals with user and group creation is elegant, 
especially if you have more than one package that needs a specific user 
and/or group combination created. When I first saw portage spit out the 
ambiguity for the request `emerge mythtv` the first thing I thought was 
"Why would I need to merge a package to create a user? That's the 
package manager's problem..." :o)

Maybe when I have a moment I'll file a bug.

Dan

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[William Kenworthy]

On 21/6/20 9:40 am, Daniel Frey wrote:
> On 6/20/20 6:21 PM, Rich Freeman wrote:
>> On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey <djqfrey@gmail.com> wrote:
>
> Maybe when I have a moment I'll file a bug.
>
> Dan
>
Thanks for filing the bug.  One of my pet peeves is that the last few
years gentoo has been going down the path of spitting everything into
smaller and smaller pieces and scattering them around - its fine when
things work, but becomes a real pig to fault find and more often ends up
in a call for help.  I would really like packages to be self contained
so its configuration and files are all in one place.  I cant see any
advantage to having multiple ebuilds for a package instead of using a
support framework to deal with it other than exposing multiple
opportunities for things to go wrong and make it harder to fix. This not
an elegant design!

BillK

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Daniel Frey]

On 6/20/20 7:04 PM, William Kenworthy wrote:
> 
> On 21/6/20 9:40 am, Daniel Frey wrote:
>> On 6/20/20 6:21 PM, Rich Freeman wrote:
>>> On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey <djqfrey@gmail.com> wrote:
>>
>> Maybe when I have a moment I'll file a bug.
>>
>> Dan
>>
> Thanks for filing the bug.  One of my pet peeves is that the last few
> years gentoo has been going down the path of spitting everything into
> smaller and smaller pieces and scattering them around - its fine when
> things work, but becomes a real pig to fault find and more often ends up
> in a call for help.  I would really like packages to be self contained
> so its configuration and files are all in one place.  I cant see any
> advantage to having multiple ebuilds for a package instead of using a
> support framework to deal with it other than exposing multiple
> opportunities for things to go wrong and make it harder to fix. This not
> an elegant design!
> 
> BillK
> 
> 
> 

They were trying to solve the problem of having multiple packages 
dependent on a single user/group - mariadb/mysql comes to mind.

By having these types of packages depend on something in the tree they 
can prevent the condition of having to remove the user/group when 
another package may still depend on it. It's kind of the opposite to the 
virtual/* packages I think, or maybe that's the beer talking.

Dan

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Rich Freeman]

On Sat, Jun 20, 2020 at 10:04 PM William Kenworthy <billk@iinet.net.au> wrote:
>
> I cant see any
> advantage to having multiple ebuilds for a package instead of using a
> support framework to deal with it other than exposing multiple
> opportunities for things to go wrong and make it harder to fix. This not
> an elegant design!

Uh, refactoring shared code into modules is generally considered the
best design.

Generally packages are split up when they are shared, or when they
have different update cycles or upstreams.  The details around the
splits vary between packages but if you cite and example it probably
will be easy to explain why that particular example was split.

KDE/Plasma was split up because it makes no sense to rebuild 500
binaries when one of them has a security update.

Those account ebuilds were split out because multiple packages could
require the same group, and this helps ensure the default uid/gid
doesn't change depending on what order you install packages in.

Packages like systemd/openrc tend to be a little more modular because
they may require integration with other things and it doesn't make
sense to replicate that integration across many versions of the
packages on both sides.

mysql-init-scripts is a separate package because it gets shared
between mysql and mariadb.  This isn't done often, but it does have
the side benefit that if there is a bug in the init.d script you don't
have to rebuild the whole database server to get a new bash script.

You have virtual packages because sometimes you want to depend on a
capability and not a specific package.  For example you need an mta to
be installed but you don't care which one it is, and so as a result
you see virtuals show up in the install list even though they don't do
anything.

A fair bit of this comes from Gentoo's flexibility.  If we didn't
support 47 different ways of doing everything it would be much easier
to create monolithic packages.

In general we tend to find the balance.  Plenty of other distros take
this MUCH further than Gentoo does - though some of this is driven by
being binary.  The same source package works for any arch, but if
you're doing a binary distro the manpages might work for everybody but
obviously anything compiled has to be split up by arch.

-- 
Rich

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Daniel Frey]

On 6/20/20 7:04 PM, William Kenworthy wrote:
> Thanks for filing the bug.  

Gah! I forgot about this!

I filed a bug now, I hope I made it clear enough. Others can pipe in 
there with comments if they like.

I did indicate the two potential proposals to correct the issue in the 
bug itself.

https://bugs.gentoo.org/729752

Dan

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[james]

On 6/26/20 12:38 PM, Daniel Frey wrote:
> On 6/20/20 7:04 PM, William Kenworthy wrote:
>> Thanks for filing the bug. 
> 
> Gah! I forgot about this!
> 
> I filed a bug now, I hope I made it clear enough. Others can pipe in 
> there with comments if they like.
> 
> I did indicate the two potential proposals to correct the issue in the 
> bug itself.
> 
> https://bugs.gentoo.org/729752
> 
> Dan

BEFORE I contribute to this bug, I'm posting here to see if others are 
or have interest, in my thoughts on this issue and my related needs for 
extreme security, via Gentoo. Below is far from complete, but it only 
provides a very snippets of my (secure) pathway forward with Gentoo.

Interesting thread, thanks to all contributors. I'd like to add 'my 
selfish' interest, as they also be espoused by other, more focused, 
gentoo users.

INTRO:

I rarely build gentoo systems, for many reasons, that are not pretty 
singularly focused. It drastically reduces security, performance and 
upgrade issues. For me, the days of a any system, having groups or 
users, are in the history books of very bad ideas. uP are so cheap and 
less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) 16 G 
map-able ram. Furthermore, SOON, usb_4 devices are going to obsolete the 
entire concept of a 'hard drive'; hence the death (my prediction) of 
groups and users on multi-USER systems, albeit slowly.

Multi-function, Multi-tasking, and light weight, focused transient 
clusters are the future. YMMV.


So solving a problem, that was real and big, decades ago, fails to look 
at the future. For me, Gentoo is future proof. I suggest a well 
documented pathway forward; totally without the concept of groups and 
users, on a typical, highly secure system. Which is now the baseline for 
real systems, particularly with a ipv4 or ipv6 static ip, that provide 
focused and highly restricted functionalities. CA servers are going 
private, as the public and root CA servers, are suspect, at best, as to 
being pristinely secure. Yes boys and girls most Certificate Authorities 
are HACK! Even the main root CAs.

The F. Feds are the original culprits, but now it is a feeding frenzy. 
The planet is now hacked, and groups and users concepts are the past. 
imho! Danger Will Robinson Danger!

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?

I build embedded G. systems. I build single purpose G systems. I build 
security G. systems (often with the ethernet, in only listen mode. I 
build G. Firewalls.
I build G. highly restricted/filtered servers. NONE of those need users 
or groups. And if they do, I can obfuscate codes to provide that need, 
to where filters and focused software gets what it needs to provide 
functions.

Yep, I'm moving to a total 'State_Machine_design' for critical services. 
Strip out every thing else.....

Am I alone, or have/are others contemplating such high secure pathways? 
I'd be fantastic to find a kernel hacker that is on the pathway of 
extreme minimization too; private email is fine; if that is in your 
wheel_house.


curiously alone?,
James

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[J. Roeleveld]

On 26 June 2020 22:03:35 CEST, james <garftd@verizon.net> wrote:
>On 6/26/20 12:38 PM, Daniel Frey wrote:
>> On 6/20/20 7:04 PM, William Kenworthy wrote:
>>> Thanks for filing the bug. 
>> 
>> Gah! I forgot about this!
>> 
>> I filed a bug now, I hope I made it clear enough. Others can pipe in 
>> there with comments if they like.
>> 
>> I did indicate the two potential proposals to correct the issue in
>the 
>> bug itself.
>> 
>> https://bugs.gentoo.org/729752
>> 
>> Dan
>
>BEFORE I contribute to this bug, I'm posting here to see if others are 
>or have interest, in my thoughts on this issue and my related needs for
>
>extreme security, via Gentoo. Below is far from complete, but it only 
>provides a very snippets of my (secure) pathway forward with Gentoo.
>
>Interesting thread, thanks to all contributors. I'd like to add 'my 
>selfish' interest, as they also be espoused by other, more focused, 
>gentoo users.
>
>INTRO:
>
>I rarely build gentoo systems, for many reasons, that are not pretty 
>singularly focused. It drastically reduces security, performance and 
>upgrade issues. For me, the days of a any system, having groups or 
>users, are in the history books of very bad ideas. uP are so cheap and 
>less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) 16 G 
>map-able ram. Furthermore, SOON, usb_4 devices are going to obsolete
>the 
>entire concept of a 'hard drive'; hence the death (my prediction) of 
>groups and users on multi-USER systems, albeit slowly.
>
>Multi-function, Multi-tasking, and light weight, focused transient 
>clusters are the future. YMMV.
>
>
>So solving a problem, that was real and big, decades ago, fails to look
>
>at the future. For me, Gentoo is future proof. I suggest a well 
>documented pathway forward; totally without the concept of groups and 
>users, on a typical, highly secure system. Which is now the baseline
>for 
>real systems, particularly with a ipv4 or ipv6 static ip, that provide 
>focused and highly restricted functionalities. CA servers are going 
>private, as the public and root CA servers, are suspect, at best, as to
>
>being pristinely secure. Yes boys and girls most Certificate
>Authorities 
>are HACK! Even the main root CAs.
>
>The F. Feds are the original culprits, but now it is a feeding frenzy. 
>The planet is now hacked, and groups and users concepts are the past. 
>imho! Danger Will Robinson Danger!
>
>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?
>
>I build embedded G. systems. I build single purpose G systems. I build 
>security G. systems (often with the ethernet, in only listen mode. I 
>build G. Firewalls.
>I build G. highly restricted/filtered servers. NONE of those need users
>
>or groups. And if they do, I can obfuscate codes to provide that need, 
>to where filters and focused software gets what it needs to provide 
>functions.
>
>Yep, I'm moving to a total 'State_Machine_design' for critical
>services. 
>Strip out every thing else.....
>
>Am I alone, or have/are others contemplating such high secure pathways?
>
>I'd be fantastic to find a kernel hacker that is on the pathway of 
>extreme minimization too; private email is fine; if that is in your 
>wheel_house.
>
>
>curiously alone?,
>James

James,

Doesn't this imply that all the software and people interacting with the systems all have root-level access?

One of the reasons MS systems were so vulnerable in the past was because they did not support seperated users. It's also still a problem with a lot of legacy systems.

As long as more than 1 person can access the system, seperate users and groups/ACLs are necessary.

Can you explain how having no users makes a system more secure?

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Jack]

On 2020.06.26 16:03, james wrote:
> On 6/26/20 12:38 PM, Daniel Frey wrote:
>> On 6/20/20 7:04 PM, William Kenworthy wrote:
>>> Thanks for filing the bug.
>> 
>> Gah! I forgot about this!
>> 
>> I filed a bug now, I hope I made it clear enough. Others can pipe in  
>> there with comments if they like.
>> 
>> I did indicate the two potential proposals to correct the issue in  
>> the bug itself.
>> 
>> https://bugs.gentoo.org/729752
>> 
>> Dan
> 
> BEFORE I contribute to this bug, I'm posting here to see if others  
> are or have interest, in my thoughts on this issue and my related  
> needs for extreme security, via Gentoo. Below is far from complete,  
> but it only provides a very snippets of my (secure) pathway forward  
> with Gentoo.
> 
> Interesting thread, thanks to all contributors. I'd like to add 'my  
> selfish' interest, as they also be espoused by other, more focused,  
> gentoo users.
> 
> INTRO:
> 
> I rarely build gentoo systems, for many reasons, that are not pretty  
> singularly focused. It drastically reduces security, performance and  
> upgrade issues. For me, the days of a any system, having groups or  
> users, are in the history books of very bad ideas. uP are so cheap  
> and less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+)  
> 16 G map-able ram. Furthermore, SOON, usb_4 devices are going to  
> obsolete the entire concept of a 'hard drive'; hence the death (my  
> prediction) of groups and users on multi-USER systems, albeit slowly.
> 
> Multi-function, Multi-tasking, and light weight, focused transient  
> clusters are the future. YMMV.
> 
> 
> So solving a problem, that was real and big, decades ago, fails to  
> look at the future. For me, Gentoo is future proof. I suggest a well  
> documented pathway forward; totally without the concept of groups and  
> users, on a typical, highly secure system. Which is now the baseline  
> for real systems, particularly with a ipv4 or ipv6 static ip, that  
> provide focused and highly restricted functionalities. CA servers are  
> going private, as the public and root CA servers, are suspect, at  
> best, as to being pristinely secure. Yes boys and girls most  
> Certificate Authorities are HACK! Even the main root CAs.
> 
> The F. Feds are the original culprits, but now it is a feeding  
> frenzy. The planet is now hacked, and groups and users concepts are  
> the past. imho! Danger Will Robinson Danger!
> 
> 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?
> 
> I build embedded G. systems. I build single purpose G systems. I  
> build security G. systems (often with the ethernet, in only listen  
> mode. I build G. Firewalls.
> I build G. highly restricted/filtered servers. NONE of those need  
> users or groups. And if they do, I can obfuscate codes to provide  
> that need, to where filters and focused software gets what it needs  
> to provide functions.
> 
> Yep, I'm moving to a total 'State_Machine_design' for critical  
> services. Strip out every thing else.....
> 
> Am I alone, or have/are others contemplating such high secure  
> pathways? I'd be fantastic to find a kernel hacker that is on the  
> pathway of extreme minimization too; private email is fine; if that  
> is in your wheel_house.
> 
> 
> curiously alone?,
> James
While you may not be alone, I do believe you're in a rather small  
group.  There are probably more who are interested in watching it  
progress than who can actually participate and contribute.  And while  
what you propose may well be part of the future, and it may even be a  
large part of it, it won't be so anywhere near soon enough to avoid the  
need to continue to improve current systems, even if the improvements  
are only usability related, and not directly related to security.  This  
current issue is nothing more than an annoyance, but it's a major  
annoyance for many Gentoo users, possibly more-so for the more casual  
users.  (Is "casual Gentoo user" an oxymoron?)  As the bug proposes,  
there are ways of solving it without decreasing security.

Jack

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[james]

On 6/26/20 4:36 PM, Jack wrote:
> On 2020.06.26 16:03, james wrote:
>> On 6/26/20 12:38 PM, Daniel Frey wrote:
>>> On 6/20/20 7:04 PM, William Kenworthy wrote:
>>>> Thanks for filing the bug.
>>>
>>> Gah! I forgot about this!
>>>
>>> I filed a bug now, I hope I made it clear enough. Others can pipe in 
>>> there with comments if they like.
>>>
>>> I did indicate the two potential proposals to correct the issue in 
>>> the bug itself.
>>>
>>> https://bugs.gentoo.org/729752
>>>
>>> Dan
>>
>> BEFORE I contribute to this bug, I'm posting here to see if others are 
>> or have interest, in my thoughts on this issue and my related needs 
>> for extreme security, via Gentoo. Below is far from complete, but it 
>> only provides a very snippets of my (secure) pathway forward with Gentoo.
>>
>> Interesting thread, thanks to all contributors. I'd like to add 'my 
>> selfish' interest, as they also be espoused by other, more focused, 
>> gentoo users.
>>
>> INTRO:
>>
>> I rarely build gentoo systems, for many reasons, that are not pretty 
>> singularly focused. It drastically reduces security, performance and 
>> upgrade issues. For me, the days of a any system, having groups or 
>> users, are in the history books of very bad ideas. uP are so cheap and 
>> less than $100, gets you a very 'bad ass' computer (Rasp. Pi 4+) 16 G 
>> map-able ram. Furthermore, SOON, usb_4 devices are going to obsolete 
>> the entire concept of a 'hard drive'; hence the death (my prediction) 
>> of groups and users on multi-USER systems, albeit slowly.
>>
>> Multi-function, Multi-tasking, and light weight, focused transient 
>> clusters are the future. YMMV.
>>
>>
>> So solving a problem, that was real and big, decades ago, fails to 
>> look at the future. For me, Gentoo is future proof. I suggest a well 
>> documented pathway forward; totally without the concept of groups and 
>> users, on a typical, highly secure system. Which is now the baseline 
>> for real systems, particularly with a ipv4 or ipv6 static ip, that 
>> provide focused and highly restricted functionalities. CA servers are 
>> going private, as the public and root CA servers, are suspect, at 
>> best, as to being pristinely secure. Yes boys and girls most 
>> Certificate Authorities are HACK! Even the main root CAs.
>>
>> The F. Feds are the original culprits, but now it is a feeding frenzy. 
>> The planet is now hacked, and groups and users concepts are the past. 
>> imho! Danger Will Robinson Danger!
>>
>> 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?
>>
>> I build embedded G. systems. I build single purpose G systems. I build 
>> security G. systems (often with the ethernet, in only listen mode. I 
>> build G. Firewalls.
>> I build G. highly restricted/filtered servers. NONE of those need 
>> users or groups. And if they do, I can obfuscate codes to provide that 
>> need, to where filters and focused software gets what it needs to 
>> provide functions.
>>
>> Yep, I'm moving to a total 'State_Machine_design' for critical 
>> services. Strip out every thing else.....
>>
>> Am I alone, or have/are others contemplating such high secure 
>> pathways? I'd be fantastic to find a kernel hacker that is on the 
>> pathway of extreme minimization too; private email is fine; if that is 
>> in your wheel_house.
>>
>>
>> curiously alone?,
>> James
> While you may not be alone, I do believe you're in a rather small 
> group.? There are probably more who are interested in watching it 
> progress than who can actually participate and contribute.? And while 
> what you propose may well be part of the future, and it may even be a 
> large part of it, it won't be so anywhere near soon enough to avoid the 
> need to continue to improve current systems, even if the improvements 
> are only usability related, and not directly related to security. 

Yep, Yep Yep.

Um, now covid hit. We've been promised much more from the next 'virus'. 
Massive security problems, for all OSes, dispersed computational issues 
and such. So, a vision (dream?) of total self sufficiency, with packets 
of really secure content traversing the fibers of the world, and a few 
smart, empower techies running a given hub, sure we can solve the 
security issues. However, the big webs are mere wide spots on the 
highway and should readily be "dynamically" replaceable; never 
critically necessary for any astute user.

And the F. Feds and their overseas counterpart?
Are left behind in the dust, for good. I think you'll see a US 
presidential candidate, whom constitutionally, recognzes the US citizens 
have a fundamental (God given?) right to superior security, as long as 
they have a very clean legal record. Boy that's a twist: well behave 
citizens get superior security righs to F. Feds? Boy, that's going to be 
a popular idea, methinks. Actually, there are many Christian lawyers, 
who know of ancient documents and USA historical documents and letters 
that expound on those documents, where this is well established. NO 
questions atm. Let folks do their own research.

We'll get there sooner than you expect...... Bank on it!
WE have to, otherwise the US banking system is DOA.

> This 
> current issue is nothing more than an annoyance, but it's a major 
> annoyance for many Gentoo users, possibly more-so for the more casual 
> users.? (Is "casual Gentoo user" an oxymoron?)? As the bug proposes, 
> there are ways of solving it without decreasing security.
> Jack


Jack, Jack, Jack.

VIVA LA REVELUTION!
and you started it all?


The USA is currently the longest standing government. The stench of what 
"our" legal system has become, well it's insufferable even by many of 
the brilliant legal minds whom have pretty much had enough of the big 
corporations running destructively, over what rights the founders of 
this great nation intended.

Lawyers, above the law? That needs to be fixed, yesterday. WE, the folks 
in good standing, have rights that supersede the legal morass of what 
the judiciary and executive branch have done by giving our rights away 
to the Corporations.

Be long, Be strong, but most importantly, Be for the benefit of equality 
of all. Rights to privacy are fundamental rights and I'd remind everyone 
that many have died for OUR RIGHTS.


hth,
James

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Rich Freeman]

On Fri, Jun 26, 2020 at 4:03 PM james <garftd@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.

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.

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.
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.

-- 
Rich

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[james]

On 6/26/20 4:40 PM, Rich Freeman wrote:
> On Fri, Jun 26, 2020 at 4:03 PM james <garftd@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

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Rich Freeman]

On Fri, Jun 26, 2020 at 10:18 PM james <garftd@verizon.net> wrote:
>
> On 6/26/20 4:40 PM, Rich Freeman wrote:
> > 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?

So, ultimately a uid/gid is just a number, and a field in a couple of
tables.  Inodes have them, and processes have them.  There might be
other things that have them that I'm not thinking of, but those are
probably the main two.

If a process wants to send signals to another process the uids have to
match, or it must have a capability to break this rule.  If a process
wants to read a file, the uid/gid/permissions/ACLs/etc must correspond
appropriately.  I'm sure there are a bunch of other system calls where
uids/gids matter as well.

The field that stores the IDs has a certain size, and thus any number
within the expressible range is valid.  You can't "get rid" of a UID
any more than you can ban the number 13.  However, since the logic is
based on matching it really doesn't matter much - if you launch a
process with a UID you intended to be "unused" it basically is
completely isolated as far as the filesystem and other processes go
since its UID doesn't match anything else (it could still touch world
read/writeable files, but that is true if it ran under a UID you
preferred that it use).

The files /etc/passwd and /etc/group are used by various system
programs to map these IDs to human-readable names, but they really
aren't part of how the kernel works.  Just about any command that can
take a username can take a user ID, and if you want to really drive
people crazy go ahead and try using numeric usernames (I believe the
IDs take precedence in command lines).

So, if you deleted /etc/{passwd,group,shadow} you could still have a
"perfectly working" linux userspace, but commands like login wouldn't
work as those use usernames and of course there would be no mapping to
passwords.  However init would still run as uid 0, and it could launch
processes with other uids, and those processes would have regular
filesystem behavior.  It wouldn't be POSIX and various things might
break, but you could have a name-less userspace just fine on linux.
The kernel itself never looks at /etc/shadow and so on - it just sees
numeric IDs.  Android is an example of an OS that makes some
substantial changes in userspace to how things like UIDs are
traditionally used (that, and the OOM killer).

Most things associated with users/groups in linux are conventions
implemented in userspace.

But, as I said, using more uids/gids in general means having more
separation.  In general it only increases security, with the caveat
that it does potentially make auditing more complex.

-- 
Rich

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Sid Spry]

On Sat, Jun 27, 2020, at 5:43 AM, Rich Freeman wrote:
> But, as I said, using more uids/gids in general means having more
> separation.  In general it only increases security, with the caveat
> that it does potentially make auditing more complex.
> 

Android's security model is uid per app. This is about as effective you can get on a mostly stock kernel. There is essentially no isolation within a uid. It's also why it is very hard to use an Android phone for anything without rooting it.

If you look at the CVEs for Android they are typically rather benign, the more persistent issue is you constantly carry the device with you.

Re: [gentoo-user] What's with all these "acct-group" ebuilds recently?

[Michael Orlitzky]

On 2020-06-26 16:03, james wrote:
> 
> BEFORE I contribute to this bug,

The bug is already fixed in a newer version of portage =)