Skip to contentSkip to conversation

Proposed patch: allow setting an hashed root password

Buildroot Superseded Lorenzo Catucci 4 participants 11 messages Mar 22, 2015 – Mar 24, 2015 1 message not in the archive

lore
Share & tools
lore

Lorenzo Catucci

author
#0 lore raw

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>

NAK
#1 lore raw

Lorenzo, All,

On 2015-03-22 16:09 +0100, Lorenzo Catucci spake thusly:

Quoted 9 lines

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.

Quoted 8 lines

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 <[email protected]>

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#2 lore raw
Quoted 16 lines · Yann E. MORIN

Lorenzo, All,

On 2015-03-22 16:09 +0100, Lorenzo Catucci spake thusly:

Quoted 13 lines

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 .

Quoted 6 lines
Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 7 lines

One (or more) paragraph explaining what you changed.

Signed-ogg-by Your Real Name <[email protected]>

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.

Quoted 6 lines

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

Quoted 4 lines

Regards,
Yann E. MORIN.

Signature · 6 lines
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
#3 lore raw

Lorenzo, All,

On 2015-03-22 17:14 +0100, Arnout Vandecappelle spake thusly:

Quoted 22 lines · Yann E. MORIN
Quoted 21 lines

Lorenzo, All,

On 2015-03-22 16:09 +0100, Lorenzo Catucci spake thusly:

Quoted 17 lines

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

Quoted 8 lines
Quoted 1 line

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! :-)

Quoted 12 lines
Quoted 12 lines

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 <[email protected]>
Quoted 7 lines
Quoted 3 lines

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.

Quoted 27 lines
Quoted 5 lines

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

Quoted 4 lines

Regards,
Yann E. MORIN.

Signature · 6 lines
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
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

A message that is not in the archive (sent off-list or not yet received): [email protected]

#5 lore raw

Lorenzo, All,

On 2015-03-22 23:14 +0100, Lorenzo M. Catucci spake thusly:

Quoted 10 lines
Quoted 7 lines
Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 9 lines
Quoted 4 lines
Quoted 4 lines

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

Quoted 9 lines
Quoted 8 lines

[snipped mkpasswd discussion, orthogonal to my proposed patch]

Quoted 6 lines
Quoted 6 lines

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

Quoted 5 lines

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?

Quoted 2 lines

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.

Quoted 3 lines

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

Quoted 2 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
#6 lore raw

Lorenze, Yann, All,

Quoted 5 lines · Yann E. MORIN

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

Quoted 8 lines

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,

Signature · 1 line
Johan
#7 lore raw

Johan, All,

On 2015-03-23 12:05 +0100, Johan Oudinet spake thusly:

Quoted 15 lines · Yann E. MORIN
Quoted 5 lines

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

Quoted 8 lines

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

Quoted 12 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
author
#8 lore raw

PATCH v2 1/1 Restructure root password handling

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 <[email protected]>
---
 system/Config.in | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 system/system.mk | 25 +++++++++++++++++++++
 2 files changed, 91 insertions(+)
system/Config.in +66 -0
index 9973cc2..f3d67ed 100644
@@ -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"
system/system.mk +25 -0
index 4a1eb4a..5cf3faf 100644
@@ -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)
Signature · 1 line
2.1.4
author
#9 lore raw

PATCH v3 1/1 Restructure root password handling

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 <[email protected]>
---
 system/Config.in | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 system/system.mk | 21 ++++++++++++++++++
 2 files changed, 87 insertions(+)
system/Config.in +66 -0
index 9973cc2..f3d67ed 100644
@@ -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"
system/system.mk +21 -0
index 4a1eb4a..c38b1e7 100644
@@ -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)
Signature · 1 line
2.1.4
#10 lore raw

PATCH v3 1/1 Restructure root password handling

Lorenzo, All,

On 2015-03-24 13:13 +0100, Lorenzo M. Catucci spake thusly:

Quoted 4 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
author
#11 lore raw
In reply to Yann E. MORIN

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

Quoted 58 lines · Yann E. MORIN

Johan, All,

On 2015-03-23 12:05 +0100, Johan Oudinet spake thusly:

Quoted 15 lines · Yann E. MORIN
Quoted 5 lines

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

Quoted 8 lines

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

Quoted 12 lines

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.

Signature · 14 lines
+-------------------------+----------------------------------------------+
| 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                        |
+-------------------------+----------------------------------------------+