[Buildroot] Proposed patch: allow setting an hashed root password

[Buildroot] Proposed patch: allow setting an hashed root password

[Lorenzo Catucci]

Please find enclosed my proposed patch. I've posted the patch to a GH fork of
the main repository too: look at the ?hashed_root_pw? branch of

	https://github.com/lmctv/buildroot

The reason I've enabled the new ?BR2_TARGET_GENERIC_ROOT_PASSWD_HASH?
configuration option is being able to set a "*" password hash for the root
user without being forced to put a static /etc/shadow inside BR2_ROOTFS_OVERLAY.

Even if setting a "real" password, I think the option to put a sha256 or
sha512 hash in the .config is a lot less scary than putting a plaintext
password, especially in the case of sha512 .

Thank you very much, yours

	lorenzo m catucci

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-setting-an-already-encrypted-root-password.patch
Type: text/x-patch
Size: 3044 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20150322/733f6eed/attachment.bin>

[Buildroot] Proposed patch: allow setting an hashed root password

[Yann E. MORIN]

Lorenzo, All,

On 2015-03-22 16:09 +0100, Lorenzo Catucci spake thusly:
> Please find enclosed my proposed patch. I've posted the patch to a GH fork of
> the main repository too: look at the ?hashed_root_pw? branch of
> 
> 	https://github.com/lmctv/buildroot
> 
> The reason I've enabled the new ?BR2_TARGET_GENERIC_ROOT_PASSWD_HASH?
> configuration option is being able to set a "*" password hash for the root
> user without being forced to put a static /etc/shadow inside BR2_ROOTFS_OVERLAY.
> 
> Even if setting a "real" password, I think the option to put a sha256 or
> sha512 hash in the .config is a lot less scary than putting a plaintext
> password, especially in the case of sha512 .
> 
> Thank you very much, yours
> 
> 	lorenzo m catucci
> 

NAK.

First, the commit log should only explain the technical reasons for the
change, and not contain "personal" messages:

    first line, short explanation

    One (or more) paragraph explainging the current situation and why
    you believe it is incorrect.

    One (or more) paragraph explaining what you changed.

    Signed-ogg-by: Your Real Name <your-email@somehwere.net>

Second, there's something odd: clearly the patch prefers the hashed
password over the clear-text one, but does not prevent the user to set
both.

Third, if you want to do tricky password handling like this, I think it
would be better if you passed a "user table" (BR2_ROOTFS_USERS_TABLES)
that defines the root user and its password, like documented in the
mkuser infra:
    http://buildroot.net/downloads/manual/manual.html#makeuser-syntax

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Proposed patch: allow setting an hashed root password

[Arnout Vandecappelle]

On 22/03/15 17:00, Yann E. MORIN wrote:
> Lorenzo, All,
> 
> On 2015-03-22 16:09 +0100, Lorenzo Catucci spake thusly:
>> Please find enclosed my proposed patch. I've posted the patch to a GH fork of
>> the main repository too: look at the ?hashed_root_pw? branch of
>>
>> 	https://github.com/lmctv/buildroot
>>
>> The reason I've enabled the new ?BR2_TARGET_GENERIC_ROOT_PASSWD_HASH?
>> configuration option is being able to set a "*" password hash for the root
>> user without being forced to put a static /etc/shadow inside BR2_ROOTFS_OVERLAY.
>>
>> Even if setting a "real" password, I think the option to put a sha256 or
>> sha512 hash in the .config is a lot less scary than putting a plaintext
>> password, especially in the case of sha512 .
>>
>> Thank you very much, yours
>>
>> 	lorenzo m catucci
>>
> 
> NAK.

 What Yann wants to say is:

 Thank you, Lorenzo, for your patch. However, you have not followed the patch
submission guidelines. Patches should be submitted in-line, preferably using git
send-email. Any "personal" comments can be added below a --- line after your
Signed-off-by.


> 
> First, the commit log should only explain the technical reasons for the
> change, and not contain "personal" messages:
> 
>     first line, short explanation
> 
>     One (or more) paragraph explainging the current situation and why
>     you believe it is incorrect.
> 
>     One (or more) paragraph explaining what you changed.
> 
>     Signed-ogg-by: Your Real Name <your-email@somehwere.net>
> 
> Second, there's something odd: clearly the patch prefers the hashed
> password over the clear-text one, but does not prevent the user to set
> both.

 Therefore, perhaps a better approach is to detect the $-pattern of an
already-encrypted password in package/mkpasswd/mkpasswd.c and skip the hashing
in that case.

> 
> Third, if you want to do tricky password handling like this, I think it
> would be better if you passed a "user table" (BR2_ROOTFS_USERS_TABLES)
> that defines the root user and its password, like documented in the
> mkuser infra:
>     http://buildroot.net/downloads/manual/manual.html#makeuser-syntax

 +1 to that.

 So perhaps a better idea is to add that to the help text of
BR2_TARGET_GENERIC_ROOT_PASSWD.

 Regards,
 Arnout

> 
> Regards,
> Yann E. MORIN.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Proposed patch: allow setting an hashed root password

[Yann E. MORIN]

Lorenzo, All,

On 2015-03-22 17:14 +0100, Arnout Vandecappelle spake thusly:
> On 22/03/15 17:00, Yann E. MORIN wrote:
> > Lorenzo, All,
> > 
> > On 2015-03-22 16:09 +0100, Lorenzo Catucci spake thusly:
> >> Please find enclosed my proposed patch. I've posted the patch to a GH fork of
> >> the main repository too: look at the ?hashed_root_pw? branch of
> >>
> >> 	https://github.com/lmctv/buildroot
> >>
> >> The reason I've enabled the new ?BR2_TARGET_GENERIC_ROOT_PASSWD_HASH?
> >> configuration option is being able to set a "*" password hash for the root
> >> user without being forced to put a static /etc/shadow inside BR2_ROOTFS_OVERLAY.
> >>
> >> Even if setting a "real" password, I think the option to put a sha256 or
> >> sha512 hash in the .config is a lot less scary than putting a plaintext
> >> password, especially in the case of sha512 .
> >>
> >> Thank you very much, yours
> >>
> >> 	lorenzo m catucci
> >>
> > 
> > NAK.
> 
>  What Yann wants to say is:
> 
>  Thank you, Lorenzo, for your patch. However, you have not followed the patch
> submission guidelines. Patches should be submitted in-line, preferably using git
> send-email. Any "personal" comments can be added below a --- line after your
> Signed-off-by.

He, yes! Thanks Arnout for expanding my thoughts! :-)

> > First, the commit log should only explain the technical reasons for the
> > change, and not contain "personal" messages:
> > 
> >     first line, short explanation
> > 
> >     One (or more) paragraph explainging the current situation and why
> >     you believe it is incorrect.
> > 
> >     One (or more) paragraph explaining what you changed.
> > 
> >     Signed-ogg-by: Your Real Name <your-email@somehwere.net>
> > 
> > Second, there's something odd: clearly the patch prefers the hashed
> > password over the clear-text one, but does not prevent the user to set
> > both.
> 
>  Therefore, perhaps a better approach is to detect the $-pattern of an
> already-encrypted password in package/mkpasswd/mkpasswd.c and skip the hashing
> in that case.

I wonder how much we can accept mkpasswd to diverge from the upstream
one we vampirised (from whois).

Actually, we currently have a whois package, so maybe we could drop our
mkpasswd package and switch to depending on host-whois instead, that
would just install mkpasswd into $(HOST_DIR). Thoughts?

Regards,
Yann E. MORIN.

> > Third, if you want to do tricky password handling like this, I think it
> > would be better if you passed a "user table" (BR2_ROOTFS_USERS_TABLES)
> > that defines the root user and its password, like documented in the
> > mkuser infra:
> >     http://buildroot.net/downloads/manual/manual.html#makeuser-syntax
> 
>  +1 to that.
> 
>  So perhaps a better idea is to add that to the help text of
> BR2_TARGET_GENERIC_ROOT_PASSWD.
> 
>  Regards,
>  Arnout
> 
> > 
> > Regards,
> > Yann E. MORIN.
> > 
> 
> 
> -- 
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Proposed patch: allow setting an hashed root password

[Yann E. MORIN]

Lorenzo, All,

On 2015-03-22 23:14 +0100, Lorenzo M. Catucci spake thusly:
> >>  Thank you, Lorenzo, for your patch. However, you have not followed the patch
> >> submission guidelines. Patches should be submitted in-line, preferably using git
> >> send-email. Any "personal" comments can be added below a --- line after your
> >> Signed-off-by.
> > 
> > He, yes! Thanks Arnout for expanding my thoughts! :-)
> > 
> 
> I've attacched the results from a straight git format-patch to avoid MUA
> reformatting problems...

You should probably use 'git send-email' which will send a proper mail
with the patch unmangled in the body.

> Sorry for not understanding buildroot's policy about
> requiring the Signed-off-by: line even from original authors. If deemed
> useful, I'll amend the commit and resend.

Yes, we require the SoB line even when the submitter is the author.

> >>> Second, there's something odd: clearly the patch prefers the hashed
> >>> password over the clear-text one, but does not prevent the user to set
> >>> both.
> >>
> >>
> 
> OK, I don't think you can reset a string option based on the presence of
> another one in KConfig; instead, I think I could add a password format choice
> defaulting to plaintext.

We could do something like:

    config BR2_TARGET_GENERIC_ROOT_PASSWD_HASHED
        string "hashed root password"
        depends on BR2_TARGET_GENERIC_ROOT_PASSWD != ""

but still I think we should strive at having a single option.

> >>  Therefore, perhaps a better approach is to detect the $-pattern of an
> >> already-encrypted password in package/mkpasswd/mkpasswd.c and skip the hashing
> >> in that case.
> >>
> 
> While we could do a regex check for  '^[^./0-9A-Za-z]' to have "*" and "!"
> starting password interpreted as already hashed too, traditional unix DES
> encrypted password would be interpreted as plaintext ones, while "!expletive"
> would be interpreted as an invalid hashed password.

Yeah.. I've been thinking of a good heuristic to differentiate a hashed
password from a plain text one, and it's not easy...

> >  [snipped mkpasswd discussion, orthogonal to my proposed patch]
> > 
> >>> Third, if you want to do tricky password handling like this, I think it
> >>> would be better if you passed a "user table" (BR2_ROOTFS_USERS_TABLES)
> >>> that defines the root user and its password, like documented in the
> >>> mkuser infra:
> >>>     http://buildroot.net/downloads/manual/manual.html#makeuser-syntax
> >>>
> 
> I don't think setting an explicit hash for the root user can count as tricky
> password handling, especially since this would mitigate a couple of real risks:
> 
>  1. a sha-256 or sha-512 hashed password is a lot less vulnerable
>     than plaintext one

Hmm... I think there's some misunderstanding here (maybe on my side).
The root password *is* encrypted before being stored into /etc/passwd.
And it is encrypted with the algorithm you can choose in the same menu
(a little bit above), and we support encoding with:
  - des
  - md5 (the default)
  - sha-256
  - sha-512

The root password is in clear only in the .config file.

Or are you concerned about leaking the .config file and that the root
password would be visible?

>  2. in the default configuration, the root user can login with an empty
>     password

So, it looks like you'd want to be able to disallow root logins, from
inside the menuconfig. Then what about adding a new option:

    config BR2_TARGET_ALLOW_ROOT_LOGIN
        bool "Allow root login"
        default y
        help
          If set to 'y' (the default), then root will be allowed to
          login, from the console or from ssh (if you have an ssh
          server.

    config BR2_TARGET_GENERIC_ROOT_PASSWD
        bool "Root password"
        depends on BR2_TARGET_ALLOW_ROOT_LOGIN

And adapt the rest accordingly.

> As for the suggestion of putting the root's password in a "user table", the
> first two lines of the "Makeusers syntax documentation" chapter talk about
> adding/creating users,

Well, it is for adding users, right, but it can also be used to "update"
an existing user (as long as there is no conflict between login/UID and
group/GID, there can be more than one deifinition of a user).

> and some lines below there is an explicit "uid is the
> desired UID for the user. It must be unique, and not 0".

Indeed, and I should have known (I wrote that!). Thanks for pointing
that! :-)

Maybe we could relax the checks, so that the 'root' user is allowed, but
only to set the password... I'll see if that can make sense, and if that
would be easily doable.

Alternatively, you could also tweak the root password from a post-build
script, see BR2_ROOTFS_POST_BUILD_SCRIPT:
    http://buildroot.net/downloads/manual/manual.html#rootfs-custom

script which could look something like:

    #!/bin/sh
    PASSWD='your-encoded-password'
    sed -r -i -e "s/^root:[^:]+:/root:${PASSWD}:/" "${TARGET_DIR}/etc/passwd"

And in the end, I wonder if that would not be the best option...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Proposed patch: allow setting an hashed root password

[Johan Oudinet]

Lorenze, Yann, All,

On Sun, Mar 22, 2015 at 11:56 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>
> Alternatively, you could also tweak the root password from a post-build
> script, see BR2_ROOTFS_POST_BUILD_SCRIPT:
>     http://buildroot.net/downloads/manual/manual.html#rootfs-custom
>
> script which could look something like:
>
>     #!/bin/sh
>     PASSWD='your-encoded-password'
>     sed -r -i -e "s/^root:[^:]+:/root:${PASSWD}:/" "${TARGET_DIR}/etc/passwd"
>
> And in the end, I wonder if that would not be the best option...
>

This is the solution we do internally. I'm not sure how hard it is for
us to send it upstream as it implies several changes. I'll look into
it this week.
Basically, we have a script to ease the access to BR2_* variables
inside post_build scripts, then we have a post_build script that looks
to BR2_TARGET_GENERIC_ROOT_PASSWD and:
- if it's empty, it does nothing;
- if it starts by $1$, $5$, or $6$, it assumes it is already
encrypted, and skip the encoding part
- otherwise, first it encodes it by calling mkpasswd with the
BR2_TARGET_GENERIC_PASSWD_METHOD method, then it replaces the second
field of the root user in the /etc/shadow file

So, one can either put a password in clear text in the .config or an
already encrypted password, which allows us to share a defconfig with
a non-empty password for root.

Best regards,
-- 
Johan

[Buildroot] Proposed patch: allow setting an hashed root password

[Yann E. MORIN]

Johan, All,

On 2015-03-23 12:05 +0100, Johan Oudinet spake thusly:
> On Sun, Mar 22, 2015 at 11:56 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> >
> > Alternatively, you could also tweak the root password from a post-build
> > script, see BR2_ROOTFS_POST_BUILD_SCRIPT:
> >     http://buildroot.net/downloads/manual/manual.html#rootfs-custom
> >
> > script which could look something like:
> >
> >     #!/bin/sh
> >     PASSWD='your-encoded-password'
> >     sed -r -i -e "s/^root:[^:]+:/root:${PASSWD}:/" "${TARGET_DIR}/etc/passwd"
> >
> > And in the end, I wonder if that would not be the best option...
> >
> 
> This is the solution we do internally. I'm not sure how hard it is for
> us to send it upstream as it implies several changes. I'll look into
> it this week.
> Basically, we have a script to ease the access to BR2_* variables
> inside post_build scripts, then we have a post_build script that looks
> to BR2_TARGET_GENERIC_ROOT_PASSWD and:
> - if it's empty, it does nothing;
> - if it starts by $1$, $5$, or $6$, it assumes it is already
> encrypted, and skip the encoding part
> - otherwise, first it encodes it by calling mkpasswd with the
> BR2_TARGET_GENERIC_PASSWD_METHOD method, then it replaces the second
> field of the root user in the /etc/shadow file

Well, recognising an md5, sha256 or sha512 hashed password from a
plain-text one is pretty trivial.

What's not so trivial is recognising:
  - a DES-encoded password
  - a disabled password, marked with a leading '!'
  - a no-login password, marked with just a single '*'

Detecting a DES-encoded password is not easy because the accepted chars
are in a sub-set as those accepted for a plain-text password.

However, maybe we could deprecate DES-encoding altogether, then we
could handle those cases:

  - password is '*'                 --> login not allowed; stop
  - password starts with '!'        --> login disabled, skip the '!'; continue
  - password starts with ${1,5,6}$  --> treat it as an encoded password; stop
  - anything else                   --> treat it as a plain-text password

That way, the existing option can be re-used for all cases, and we would
not need anything more, just adapting the current code in system/system.mk.

Thoughts?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2] Restructure root password handling

[Lorenzo M. Catucci]

Created a top level boolean entry to enable/disable root login

Allow choosing the root password input format only if root login
is enabled.

Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
---
 system/Config.in | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 system/system.mk | 25 +++++++++++++++++++++
 2 files changed, 91 insertions(+)

diff --git a/system/Config.in b/system/Config.in
index 9973cc2..f3d67ed 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -188,6 +188,44 @@ endif
 
 if BR2_ROOTFS_SKELETON_DEFAULT
 
+config BR2_TARGET_ENABLE_ROOT_LOGIN
+	bool "Enable root login"
+        default "y"
+	help
+	  Enable root login password
+
+if BR2_TARGET_ENABLE_ROOT_LOGIN
+
+choice
+	prompt "Root password input"
+
+config BR2_TARGET_PLAINTEXT_ROOT_PASSWORD
+	bool "cleartext format"
+	help
+	  Set the root password from plaintext input
+
+	  WARNING! WARNING!
+	  The password appears in clear in the .config file, and may appear
+	  in the build log! Avoid using a valuable password if either the
+	  .config file or the build log may be distributed!
+
+config BR2_TARGET_HASHED_ROOT_PASSWORD
+	bool "hashed format"
+	help
+	  Set the root password from prehashed input
+
+	  WARNING! WARNING!
+	  The password's hash appears in the .config file, and may appear
+	  in the build log! Avoid using a valuable password if either
+	  the .config file or the build log may be distributed, or at the
+	  very least use a strong cryptographic hash for your password!
+
+endchoice
+
+endif
+
+if BR2_TARGET_PLAINTEXT_ROOT_PASSWORD
+
 config BR2_TARGET_GENERIC_ROOT_PASSWD
 	string "Root password"
 	default ""
@@ -208,6 +246,34 @@ config BR2_TARGET_GENERIC_ROOT_PASSWD
 	  The password appears in clear in the .config file, and may appear
 	  in the build log! Avoid using a valuable password if either the
 	  .config file or the build log may be distributed!
+endif
+
+if BR2_TARGET_HASHED_ROOT_PASSWORD
+
+config BR2_TARGET_GENERIC_ROOT_PASSWD_HASH
+	string "Hashed root password"
+	default ""
+	help
+	  Set the crypt(3) encoded root password hash.
+
+	  If set to empty (the default), then no root password will be set,
+	  and root will need no password to log in.
+
+	  An hashed root password of "*" will disable root logins.
+
+	  "$" signs in the hashed password must be doubled.
+
+	  For example, the MD5 hash for the password "mypass" salted with
+	  the string "longsalt" is "$1$longsalt$v35DIIeMo4yUfI23yditq0",
+	  which must be written as "$$1$$longsalt$$v35DIIeMo4yUfI23yditq0"
+
+	  WARNING! WARNING!
+	  The password's hash appears in the .config file, and may appear
+	  in the build log! Avoid using a valuable password if either
+	  the .config file or the build log may be distributed, or at the
+	  very least use a strong cryptographic hash for your password!
+
+endif
 
 choice
 	bool "/bin/sh"
diff --git a/system/system.mk b/system/system.mk
index 4a1eb4a..5cf3faf 100644
--- a/system/system.mk
+++ b/system/system.mk
@@ -1,6 +1,10 @@
 TARGET_GENERIC_HOSTNAME = $(call qstrip,$(BR2_TARGET_GENERIC_HOSTNAME))
 TARGET_GENERIC_ISSUE = $(call qstrip,$(BR2_TARGET_GENERIC_ISSUE))
+TARGET_ENABLE_ROOT_LOGIN = $(call qstrip, $(BR2_TARGET_ENABLE_ROOT_LOGIN))
+TARGET_PLAINTEXT_ROOT_PASSWORD = $(call qstrip, $(BR2_TARGET_PLAINTEXT_ROOT_PASSWORD))
+TARGET_HASHED_ROOT_PASSWORD = $(call qstrip, $(BR2_TARGET_HASHED_ROOT_PASSWORD))
 TARGET_GENERIC_ROOT_PASSWD = $(call qstrip,$(BR2_TARGET_GENERIC_ROOT_PASSWD))
+TARGET_GENERIC_ROOT_PASSWD_HASH = $(call qstrip,$(BR2_TARGET_GENERIC_ROOT_PASSWD_HASH))
 TARGET_GENERIC_PASSWD_METHOD = $(call qstrip,$(BR2_TARGET_GENERIC_PASSWD_METHOD))
 TARGET_GENERIC_BIN_SH = $(call qstrip,$(BR2_SYSTEM_BIN_SH))
 TARGET_GENERIC_GETTY_PORT = $(call qstrip,$(BR2_TARGET_GENERIC_GETTY_PORT))
@@ -69,11 +73,32 @@ TARGET_FINALIZE_HOOKS += SET_NETWORK
 
 ifeq ($(BR2_ROOTFS_SKELETON_DEFAULT),y)
 
+ifeq ($(TARGET_ENABLE_ROOT_LOGIN),y)
+
+ifeq ($(BR2_TARGET_PLAINTEXT_ROOT_PASSWORD),y)
+
 define SYSTEM_ROOT_PASSWD
 	[ -n "$(TARGET_GENERIC_ROOT_PASSWD)" ] && \
 		TARGET_GENERIC_ROOT_PASSWD_HASH=$$($(MKPASSWD) -m "$(TARGET_GENERIC_PASSWD_METHOD)" "$(TARGET_GENERIC_ROOT_PASSWD)"); \
 	$(SED) "s,^root:[^:]*:,root:$$TARGET_GENERIC_ROOT_PASSWD_HASH:," $(TARGET_DIR)/etc/shadow
 endef
+
+else ifeq ($(BR2_TARGET_HASHED_ROOT_PASSWORD),y)
+
+define SYSTEM_ROOT_PASSWD
+	$(SED) 's,^root:[^:]*:,root:$(TARGET_GENERIC_ROOT_PASSWD_HASH):,' $(TARGET_DIR)/etc/shadow
+endef
+
+endif
+
+else
+
+define SYSTEM_ROOT_PASSWD
+	$(SED) 's,^root:[^:]*:,root:*:,' $(TARGET_DIR)/etc/shadow
+endef
+
+endif
+
 TARGET_FINALIZE_HOOKS += SYSTEM_ROOT_PASSWD
 
 ifeq ($(BR2_SYSTEM_BIN_SH_NONE),y)
-- 
2.1.4

[Buildroot] [PATCH v3] Restructure root password handling

[Lorenzo M. Catucci]

Created a top level boolean entry to enable/disable root login

Allow choosing the root password input format only if root login
is enabled.

Signed-off-by: Lorenzo M. Catucci <lorenzo@sancho.ccd.uniroma2.it>
---
 system/Config.in | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 system/system.mk | 21 ++++++++++++++++++
 2 files changed, 87 insertions(+)

diff --git a/system/Config.in b/system/Config.in
index 9973cc2..f3d67ed 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -188,6 +188,44 @@ endif
 
 if BR2_ROOTFS_SKELETON_DEFAULT
 
+config BR2_TARGET_ENABLE_ROOT_LOGIN
+	bool "Enable root login"
+        default "y"
+	help
+	  Enable root login password
+
+if BR2_TARGET_ENABLE_ROOT_LOGIN
+
+choice
+	prompt "Root password input"
+
+config BR2_TARGET_PLAINTEXT_ROOT_PASSWORD
+	bool "cleartext format"
+	help
+	  Set the root password from plaintext input
+
+	  WARNING! WARNING!
+	  The password appears in clear in the .config file, and may appear
+	  in the build log! Avoid using a valuable password if either the
+	  .config file or the build log may be distributed!
+
+config BR2_TARGET_HASHED_ROOT_PASSWORD
+	bool "hashed format"
+	help
+	  Set the root password from prehashed input
+
+	  WARNING! WARNING!
+	  The password's hash appears in the .config file, and may appear
+	  in the build log! Avoid using a valuable password if either
+	  the .config file or the build log may be distributed, or at the
+	  very least use a strong cryptographic hash for your password!
+
+endchoice
+
+endif
+
+if BR2_TARGET_PLAINTEXT_ROOT_PASSWORD
+
 config BR2_TARGET_GENERIC_ROOT_PASSWD
 	string "Root password"
 	default ""
@@ -208,6 +246,34 @@ config BR2_TARGET_GENERIC_ROOT_PASSWD
 	  The password appears in clear in the .config file, and may appear
 	  in the build log! Avoid using a valuable password if either the
 	  .config file or the build log may be distributed!
+endif
+
+if BR2_TARGET_HASHED_ROOT_PASSWORD
+
+config BR2_TARGET_GENERIC_ROOT_PASSWD_HASH
+	string "Hashed root password"
+	default ""
+	help
+	  Set the crypt(3) encoded root password hash.
+
+	  If set to empty (the default), then no root password will be set,
+	  and root will need no password to log in.
+
+	  An hashed root password of "*" will disable root logins.
+
+	  "$" signs in the hashed password must be doubled.
+
+	  For example, the MD5 hash for the password "mypass" salted with
+	  the string "longsalt" is "$1$longsalt$v35DIIeMo4yUfI23yditq0",
+	  which must be written as "$$1$$longsalt$$v35DIIeMo4yUfI23yditq0"
+
+	  WARNING! WARNING!
+	  The password's hash appears in the .config file, and may appear
+	  in the build log! Avoid using a valuable password if either
+	  the .config file or the build log may be distributed, or at the
+	  very least use a strong cryptographic hash for your password!
+
+endif
 
 choice
 	bool "/bin/sh"
diff --git a/system/system.mk b/system/system.mk
index 4a1eb4a..c38b1e7 100644
--- a/system/system.mk
+++ b/system/system.mk
@@ -1,6 +1,10 @@
 TARGET_GENERIC_HOSTNAME = $(call qstrip,$(BR2_TARGET_GENERIC_HOSTNAME))
 TARGET_GENERIC_ISSUE = $(call qstrip,$(BR2_TARGET_GENERIC_ISSUE))
+TARGET_ENABLE_ROOT_LOGIN = $(call qstrip, $(BR2_TARGET_ENABLE_ROOT_LOGIN))
+TARGET_PLAINTEXT_ROOT_PASSWORD = $(call qstrip, $(BR2_TARGET_PLAINTEXT_ROOT_PASSWORD))
+TARGET_HASHED_ROOT_PASSWORD = $(call qstrip, $(BR2_TARGET_HASHED_ROOT_PASSWORD))
 TARGET_GENERIC_ROOT_PASSWD = $(call qstrip,$(BR2_TARGET_GENERIC_ROOT_PASSWD))
+TARGET_GENERIC_ROOT_PASSWD_HASH = $(call qstrip,$(BR2_TARGET_GENERIC_ROOT_PASSWD_HASH))
 TARGET_GENERIC_PASSWD_METHOD = $(call qstrip,$(BR2_TARGET_GENERIC_PASSWD_METHOD))
 TARGET_GENERIC_BIN_SH = $(call qstrip,$(BR2_SYSTEM_BIN_SH))
 TARGET_GENERIC_GETTY_PORT = $(call qstrip,$(BR2_TARGET_GENERIC_GETTY_PORT))
@@ -69,11 +73,28 @@ TARGET_FINALIZE_HOOKS += SET_NETWORK
 
 ifeq ($(BR2_ROOTFS_SKELETON_DEFAULT),y)
 
+ifeq ($(TARGET_ENABLE_ROOT_LOGIN),n)
+
+define SYSTEM_ROOT_PASSWD
+	$(SED) 's,^root:[^:]*:,root:*:,' $(TARGET_DIR)/etc/shadow
+endef
+
+else ifeq ($(TARGET_PLAINTEXT_ROOT_PASSWORD),y)
+
 define SYSTEM_ROOT_PASSWD
 	[ -n "$(TARGET_GENERIC_ROOT_PASSWD)" ] && \
 		TARGET_GENERIC_ROOT_PASSWD_HASH=$$($(MKPASSWD) -m "$(TARGET_GENERIC_PASSWD_METHOD)" "$(TARGET_GENERIC_ROOT_PASSWD)"); \
 	$(SED) "s,^root:[^:]*:,root:$$TARGET_GENERIC_ROOT_PASSWD_HASH:," $(TARGET_DIR)/etc/shadow
 endef
+
+else ifeq ($(BR2_TARGET_HASHED_ROOT_PASSWORD),y)
+
+define SYSTEM_ROOT_PASSWD
+	$(SED) 's,^root:[^:]*:,root:$(TARGET_GENERIC_ROOT_PASSWD_HASH):,' $(TARGET_DIR)/etc/shadow
+endef
+
+endif
+
 TARGET_FINALIZE_HOOKS += SYSTEM_ROOT_PASSWD
 
 ifeq ($(BR2_SYSTEM_BIN_SH_NONE),y)
-- 
2.1.4

[Buildroot] [PATCH v3] Restructure root password handling

[Yann E. MORIN]

Lorenzo, All,

On 2015-03-24 13:13 +0100, Lorenzo M. Catucci spake thusly:
> Created a top level boolean entry to enable/disable root login
> 
> Allow choosing the root password input format only if root login
> is enabled.

I've sent an updated two-patch series that should supersedes that one.
It is much simpler (IMHO), and more in-line with what we would be
ready to accept, I guess.

Thank you for providing this initial work! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Proposed patch: allow setting an hashed root password

[Lorenzo M. Catucci]

I've just sent another proposed patch; this time I've put in an explicit
choice to disable root login (that was my original need), and a separate
choice for hashed or cleartext input format.

In my opinion, if the project chooses to handle password setting from a script
instead than from the makefile, the input format should be the same used in
the usermap, even though this would then force to change the semantics of
BR2_TARGET_GENERIC_ROOT_PASSWD...

Thank you very much, yours

	lorenzo

On 23/03/2015 19:48, Yann E. MORIN wrote:
> Johan, All,
> 
> On 2015-03-23 12:05 +0100, Johan Oudinet spake thusly:
>> On Sun, Mar 22, 2015 at 11:56 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>>>
>>> Alternatively, you could also tweak the root password from a post-build
>>> script, see BR2_ROOTFS_POST_BUILD_SCRIPT:
>>>     http://buildroot.net/downloads/manual/manual.html#rootfs-custom
>>>
>>> script which could look something like:
>>>
>>>     #!/bin/sh
>>>     PASSWD='your-encoded-password'
>>>     sed -r -i -e "s/^root:[^:]+:/root:${PASSWD}:/" "${TARGET_DIR}/etc/passwd"
>>>
>>> And in the end, I wonder if that would not be the best option...
>>>
>>
>> This is the solution we do internally. I'm not sure how hard it is for
>> us to send it upstream as it implies several changes. I'll look into
>> it this week.
>> Basically, we have a script to ease the access to BR2_* variables
>> inside post_build scripts, then we have a post_build script that looks
>> to BR2_TARGET_GENERIC_ROOT_PASSWD and:
>> - if it's empty, it does nothing;
>> - if it starts by $1$, $5$, or $6$, it assumes it is already
>> encrypted, and skip the encoding part
>> - otherwise, first it encodes it by calling mkpasswd with the
>> BR2_TARGET_GENERIC_PASSWD_METHOD method, then it replaces the second
>> field of the root user in the /etc/shadow file
> 
> Well, recognising an md5, sha256 or sha512 hashed password from a
> plain-text one is pretty trivial.
> 
> What's not so trivial is recognising:
>   - a DES-encoded password
>   - a disabled password, marked with a leading '!'
>   - a no-login password, marked with just a single '*'
> 
> Detecting a DES-encoded password is not easy because the accepted chars
> are in a sub-set as those accepted for a plain-text password.
> 
> However, maybe we could deprecate DES-encoding altogether, then we
> could handle those cases:
> 
>   - password is '*'                 --> login not allowed; stop
>   - password starts with '!'        --> login disabled, skip the '!'; continue
>   - password starts with ${1,5,6}$  --> treat it as an encoded password; stop
>   - anything else                   --> treat it as a plain-text password
> 
> That way, the existing option can be re-used for all cases, and we would
> not need anything more, just adapting the current code in system/system.mk.
> 
> Thoughts?
> 
> Regards,
> Yann E. MORIN.
> 


-- 
+-------------------------+----------------------------------------------+
| Lorenzo M. Catucci      | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY  |
| Tel. +39 06 7259 2255   | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+

-- 
+-------------------------+----------------------------------------------+
| Lorenzo M. Catucci      | Centro di Calcolo e Documentazione           |
| catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" |
|                         | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY  |
| Tel. +39 06 7259 2255   | Fax. +39 06 7259 2125                        |
+-------------------------+----------------------------------------------+