[gentoo-dev] A policy to support random superuser account names

[gentoo-dev] A policy to support random superuser account names

[Michał Górny]

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

Hello,

I would like to put an emphasis on the fact that many eclasses
and ebuilds in gx86 are relying on an assumption that the superuser
account is always supposed to be named 'root'.

In fact, no such constraint exists. Although most users will never even
think of changing the superuser account name, it is perfectly legit
to do so, and to use any name for that account. Moreover, it is
perfectly legit to name an unprivileged user 'root' too.

Thus, the above assumption is clearly incorrect and may result in many
issues with ebuilds using it. These range from builds failing because
of chown 'invalid user' error to packages being installed with
incorrect file ownership.

From what I've heard already, similar problem has hit Gentoo/*BSD users
already, with superuser group not being named 'root'. Although some
files were fixed to properly use numeric GID in the specific case,
no UID-related changes were done.

Moreover, not all developers agree with the case being an issue,
and they even refuse patches clearly fixing it [1]. Thus, I guess that
a clear policy regarding referencing the superuser account should be
enforced.

In my opinion, that policy should clearly indicate that the numeric
UID/GID should be always used for referencing the superuser account
as they are fixed unlike the names.

[1] http://bugs.gentoo.org/show_bug.cgi?id=315779

-- 
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] A policy to support random superuser account names

[Fabian Groffen]

On 30-04-2010 20:07:26 +0200, Michał Górny wrote:
> In my opinion, that policy should clearly indicate that the numeric
> UID/GID should be always used for referencing the superuser account
> as they are fixed unlike the names.

Just to complicate matters a bit, there are platforms where the
equivalent of "root" does not have uid = 0.  So if you want to do it
right, you probably use a variable or two that define for the host in
use what/who the root user is.  Much like we (the Prefix guys) already
store in Portage who is supposed to be the "portage" user, and who is
the "root" user, similar for their groups.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] A policy to support random superuser account names

[Alec Warner]

On Fri, Apr 30, 2010 at 11:07 AM, Michał Górny <gentoo@mgorny.alt.pl> wrote:
> Hello,
>
> I would like to put an emphasis on the fact that many eclasses
> and ebuilds in gx86 are relying on an assumption that the superuser
> account is always supposed to be named 'root'.
>
> In fact, no such constraint exists. Although most users will never even
> think of changing the superuser account name, it is perfectly legit
> to do so, and to use any name for that account. Moreover, it is
> perfectly legit to name an unprivileged user 'root' too.

Whether it is legitimate or not is irrelevant.  Users can chose to do
all sorts of legitimate but in the end utterly retarded things to
their systems and developers chose whether or not to support them.
gcc flags are a common case here (I can legitimately set a number of
flags; but most developers ignore reports with odd flags.)

>
> Thus, the above assumption is clearly incorrect and may result in many
> issues with ebuilds using it. These range from builds failing because
> of chown 'invalid user' error to packages being installed with
> incorrect file ownership.

I'd say the assumption is correct in 95% of cases; so it remains a useful one.

>
> From what I've heard already, similar problem has hit Gentoo/*BSD users
> already, with superuser group not being named 'root'. Although some
> files were fixed to properly use numeric GID in the specific case,
> no UID-related changes were done.
>
> Moreover, not all developers agree with the case being an issue,
> and they even refuse patches clearly fixing it [1]. Thus, I guess that
> a clear policy regarding referencing the superuser account should be
> enforced.

Users do a number of utterly ridiculous things to their system and
developers are free to reject bug reports for any number of reasons
(this being one of them.)

>
> In my opinion, that policy should clearly indicate that the numeric
> UID/GID should be always used for referencing the superuser account
> as they are fixed unlike the names.

Except as stated they are not fixed (as Fabian pointed out).  I'm
happy to support something like setting ROOT_UID and ROOT_GID in
gentoo-x86 profiles and using those.  Then if you want to do something
utterly ridiculous to your system you can just set the appropriate
variables.

This will likely take a GLEP though; plus it is a major change to a
lot of software we have; are you willing to make said changes?  Making
a proposal like this is all well and good but you are asking for a lot
of work to be done for what is essentially very little gain for users.

-A

>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779
>
> --
> Best regards,
> Michał Górny
>
> <http://mgorny.alt.pl>
> <xmpp:mgorny@jabber.ru>
>

Re: [gentoo-dev] A policy to support random superuser account names

[Alec Warner]

On Fri, Apr 30, 2010 at 11:07 AM, Michał Górny <gentoo@mgorny.alt.pl> wrote:
> Hello,
>
> I would like to put an emphasis on the fact that many eclasses
> and ebuilds in gx86 are relying on an assumption that the superuser
> account is always supposed to be named 'root'.
>
> In fact, no such constraint exists. Although most users will never even
> think of changing the superuser account name, it is perfectly legit
> to do so, and to use any name for that account. Moreover, it is
> perfectly legit to name an unprivileged user 'root' too.

Whether it is legitimate or not is irrelevant.  Users can chose to do
all sorts of legitimate but in the end utterly retarded things to
their systems and developers chose whether or not to support them.
gcc flags are a common case here (I can legitimately set a number of
flags; but most developers ignore reports with odd flags.)

>
> Thus, the above assumption is clearly incorrect and may result in many
> issues with ebuilds using it. These range from builds failing because
> of chown 'invalid user' error to packages being installed with
> incorrect file ownership.

I'd say the assumption is correct in 95% of cases; so it remains a useful one.

>
> From what I've heard already, similar problem has hit Gentoo/*BSD users
> already, with superuser group not being named 'root'. Although some
> files were fixed to properly use numeric GID in the specific case,
> no UID-related changes were done.
>
> Moreover, not all developers agree with the case being an issue,
> and they even refuse patches clearly fixing it [1]. Thus, I guess that
> a clear policy regarding referencing the superuser account should be
> enforced.

Users do a number of utterly ridiculous things to their system and
developers are free to reject bug reports for any number of reasons
(this being one of them.)

>
> In my opinion, that policy should clearly indicate that the numeric
> UID/GID should be always used for referencing the superuser account
> as they are fixed unlike the names.

Except as stated they are not fixed (as Fabian pointed out).  I'm
happy to support something like setting ROOT_UID and ROOT_GID in
gentoo-x86 profiles and using those.  Then if you want to do something
utterly ridiculous to your system you can just set the appropriate
variables.

This will likely take a GLEP though; plus it is a major change to a
lot of software we have; are you willing to make said changes?  Making
a proposal like this is all well and good but you are asking for a lot
of work to be done for what is essentially very little gain for users.

-A

>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779
>
> --
> Best regards,
> Michał Górny
>
> <http://mgorny.alt.pl>
> <xmpp:mgorny@jabber.ru>
>

Re: [gentoo-dev] A policy to support random superuser account names

[Enrico Weigelt]

* Alec Warner <antarus@gentoo.org> schrieb:

> Except as stated they are not fixed (as Fabian pointed out).  I'm
> happy to support something like setting ROOT_UID and ROOT_GID in
> gentoo-x86 profiles and using those.  Then if you want to do something
> utterly ridiculous to your system you can just set the appropriate
> variables.

ACK. But it should also be possible to specify names here 
(not just numerical IDs), just in case the underlying kernel
doesnt have numerical UIDs at all ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [gentoo-dev] A policy to support random superuser account names

[Michał Górny]

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

On Sun, 2 May 2010 23:57:53 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> * Alec Warner <antarus@gentoo.org> schrieb:
> 
> > Except as stated they are not fixed (as Fabian pointed out).  I'm
> > happy to support something like setting ROOT_UID and ROOT_GID in
> > gentoo-x86 profiles and using those.  Then if you want to do
> > something utterly ridiculous to your system you can just set the
> > appropriate variables.
> 
> ACK. But it should also be possible to specify names here 
> (not just numerical IDs), just in case the underlying kernel
> doesnt have numerical UIDs at all ...

Most tools which would use these variables (chown, find, install)
support both numerical UIDs and usernames passed in the same way.

-- 
Best regards,
Michał Górny

<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] A policy to support random superuser account names

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1122 bytes --]

On Monday 03 May 2010 03:31:08 Michał Górny wrote:
> On Sun, 2 May 2010 23:57:53 +0200 Enrico Weigelt wrote:
> > * Alec Warner <antarus@gentoo.org> schrieb:
> > > Except as stated they are not fixed (as Fabian pointed out).  I'm
> > > happy to support something like setting ROOT_UID and ROOT_GID in
> > > gentoo-x86 profiles and using those.  Then if you want to do
> > > something utterly ridiculous to your system you can just set the
> > > appropriate variables.
> > 
> > ACK. But it should also be possible to specify names here
> > (not just numerical IDs), just in case the underlying kernel
> > doesnt have numerical UIDs at all ...
> 
> Most tools which would use these variables (chown, find, install)
> support both numerical UIDs and usernames passed in the same way.

technically speaking, all values given to chown/etc... get looked up as a name 
first even if it is only numbers.  so if you named an account "0", then `chown 
0 foo` would not change it to UID 0, it would change it to the UID of the 
account named "0".

ROOT_{USER,GROUP} makes more sense than ROOT_{UID,GID}
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] A policy to support random superuser account names

[Stefan Behte]

Hi,

in some environments you have to rename "root" to something else, just
to be compliant to a (maybe dumb) security policy. This might be the
case for PCI, and as far as I remember, it is necessary (not just
"recommended") for a BSI Grundschutz certification (meaning something
like "basic security protection") [1]. Unfortunately I didn't find the
exact link.
This might prevent or make usage of gentoo more complicated in those
environments, but is only a problem for a small fraction of our user base.

Best regards,

Craig


[1]
https://www.bsi.bund.de/cln_183/ContentBSI/EN/Publications/Bsi_standards/standards.html

30.04.2010 20:07, Michał Górny wrote:
> Hello,
> 
> I would like to put an emphasis on the fact that many eclasses
> and ebuilds in gx86 are relying on an assumption that the superuser
> account is always supposed to be named 'root'.
> 
> In fact, no such constraint exists. Although most users will never even
> think of changing the superuser account name, it is perfectly legit
> to do so, and to use any name for that account. Moreover, it is
> perfectly legit to name an unprivileged user 'root' too.
> 
> Thus, the above assumption is clearly incorrect and may result in many
> issues with ebuilds using it. These range from builds failing because
> of chown 'invalid user' error to packages being installed with
> incorrect file ownership.
> 
> From what I've heard already, similar problem has hit Gentoo/*BSD users
> already, with superuser group not being named 'root'. Although some
> files were fixed to properly use numeric GID in the specific case,
> no UID-related changes were done.
> 
> Moreover, not all developers agree with the case being an issue,
> and they even refuse patches clearly fixing it [1]. Thus, I guess that
> a clear policy regarding referencing the superuser account should be
> enforced.
> 
> In my opinion, that policy should clearly indicate that the numeric
> UID/GID should be always used for referencing the superuser account
> as they are fixed unlike the names.
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779
> 

Re: [gentoo-dev] A policy to support random superuser account names

[Krzysztof Pawlik]

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

On 05/02/10 16:13, Stefan Behte wrote:
> Hi,
> 
> in some environments you have to rename "root" to something else, just
> to be compliant to a (maybe dumb) security policy. This might be the
> case for PCI, and as far as I remember, it is necessary (not just
> "recommended") for a BSI Grundschutz certification (meaning something
> like "basic security protection") [1]. Unfortunately I didn't find the
> exact link.

Interesting... to me that's not only stupid but also kinda useless - there's no
difference between brute-forcing a password for user named 'foo' or 'root' -
user name doesn't matter much. Actually according to my ssh logs attackers
usually don't even try root, they try other user account names way more often.
Keep in mind that most compromised systems are used to send spam, take part in
DoS attacks, etc - you don't need root to do that. Breaking into root account
may actually be harmful as it may trip some security measures.

It's better to disable password-based remote login altogether in sshd_config.
Security by obscurity is a nice way to make pseudo-sys-admins feel warm and fuzzy :]

> This might prevent or make usage of gentoo more complicated in those
> environments, but is only a problem for a small fraction of our user base.
> 
> Best regards,
> 
> Craig
> 
> 
> [1]
> https://www.bsi.bund.de/cln_183/ContentBSI/EN/Publications/Bsi_standards/standards.html
> 
> 30.04.2010 20:07, Michał Górny wrote:
>> Hello,
>>
>> I would like to put an emphasis on the fact that many eclasses
>> and ebuilds in gx86 are relying on an assumption that the superuser
>> account is always supposed to be named 'root'.
>>
>> In fact, no such constraint exists. Although most users will never even
>> think of changing the superuser account name, it is perfectly legit
>> to do so, and to use any name for that account. Moreover, it is
>> perfectly legit to name an unprivileged user 'root' too.
>>
>> Thus, the above assumption is clearly incorrect and may result in many
>> issues with ebuilds using it. These range from builds failing because
>> of chown 'invalid user' error to packages being installed with
>> incorrect file ownership.
>>
>> From what I've heard already, similar problem has hit Gentoo/*BSD users
>> already, with superuser group not being named 'root'. Although some
>> files were fixed to properly use numeric GID in the specific case,
>> no UID-related changes were done.
>>
>> Moreover, not all developers agree with the case being an issue,
>> and they even refuse patches clearly fixing it [1]. Thus, I guess that
>> a clear policy regarding referencing the superuser account should be
>> enforced.
>>
>> In my opinion, that policy should clearly indicate that the numeric
>> UID/GID should be always used for referencing the superuser account
>> as they are fixed unlike the names.
>>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=315779
>>
> 
> 
> 


-- 
Krzysztof Pawlik  <nelchael at gentoo.org>  key id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: [gentoo-dev] A policy to support random superuser account names

[Stefan Behte]

02.05.2010 17:23, Krzysztof Pawlik wrote:
> Interesting... to me that's not only stupid but also kinda useless - there's no
> difference between brute-forcing a password for user named 'foo' or 'root' -
> user name doesn't matter much.
> It's better to disable password-based remote login altogether in
sshd_config.
> Security by obscurity is a nice way to make pseudo-sys-admins feel
warm and fuzzy :]

The username is 50% of what you need to know to be able to log in, and
security by obscurity can support environments where the attacker cannot
gain insight easily, in contrast to e.g. security by obscurity in
hardware like telephones that are shipped to you and can be examined
closely.

However, it cannot be seen as effective countermeasure against attacks
and AFAIR the BSI also says, that you shouldn't allow root logins and
need a second user for logging in. All of it is a bit ridiculous,
because when you're in a position to try gaining uid 0, you probably can
read /etc/passwd already.

So, of course, it's really dumb and only creates problems. One can try
to explain that to an auditor - but it will cause not only a few
problems and definitively delay and/or endanger your certification, if
this was a "MUST" and not a "SHOULD". If it is a "SHOULD", you need to
explain (in convincing written form, of course) why you do not want to
implement it.


Back to topic: I think it would be nice be able to rename root, but I'm
not sure how much work this is, and doubt many people would actually
benefit from it.

In scripts I use to deploy things to both BSI and non-BSI systems, I'm
simply using "chown 0:0 foo". I think we could do that in our eclasses
without breaking things, but helping poor souls that renamed root. ;)
A quick look revealed that the tetex.eclass already does this and that
there are several other eclasses that use "chown -R root:0".

Best regards,

Craig

Re: [gentoo-dev] A policy to support random superuser account names

[Enrico Weigelt]

* Krzysztof Pawlik <nelchael@gentoo.org> schrieb:

> Interesting... to me that's not only stupid but also kinda useless - there's no
> difference between brute-forcing a password for user named 'foo' or 'root' -
> user name doesn't matter much. Actually according to my ssh logs attackers
> usually don't even try root, they try other user account names way more often.

ACK. And if you're really frightened of someone cracking the user "root"'s 
password/key, you simply could lock that account and add another superuser.

Keep in mind, these BSI guys are beaurocrats, not hackers. If they were
hackers, they'd prefer source distros over binary ones to add more randomness
to the overall installed machine code ... 


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

Re: [gentoo-dev] A policy to support random superuser account names

[Enrico Weigelt]

* Stefan Behte <craig@gentoo.org> schrieb:

> in some environments you have to rename "root" to something else, just
> to be compliant to a (maybe dumb) security policy. This might be the
> case for PCI, and as far as I remember, it is necessary (not just
> "recommended") for a BSI Grundschutz certification (meaning something
> like "basic security protection") [1]. Unfortunately I didn't find the
> exact link.

Well, the BSI probably isn't such a good reference point. They officially
approved "secure" infrastructures for govermental crimes ... ;-o


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------