Configuring user accounts

As I have hinted already, it is not good practice to run all programs as root since, if one is compromised by an outside attack, then the whole system is at risk and a misbehaving program can do more damage if it is running as root. It is preferable to create unprivileged user accounts and use them where full root is not necessary.

User names are configured in /etc/passwd. There is one line per user, with seven fields of information separated by colons:

  • The login name
  • A hash code used to verify the password , or more usually an x to indicate that the password is stored in /etc/shadow
  • UID
  • GID
  • A comment field, often left blank
  • The user's home directory
  • (Optional) the shell this user will use

For example, this creates users root with UID 0 and daemon with UID 1:

root:x:0:0:root:/root:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/false

Setting the shell for user daemon to /bin/false ensures that any attempt to log on with that name will fail.

Note

Various programs have to read /etc/passwd so as to be able to look up UIDs and names, and so it has to be word-readable. That is a problem if the password hashes are stored in there because a malicious program would be able to take a copy and discover the actual passwords using a variety of cracker programs. Therefore, to reduce the exposure of this sensitive information, the passwords are stored in /etc/shadow and an x is placed in the password field to indicate that this is the case. /etc/shadow is only accessible as root, and, so as long as the root user is restricted, the passwords are safe.

The shadow password file consists of one entry per user, made up of nine fields. Here is an example that mirrors the passwd file shown in the preceding paragraph:

root::10933:0:99999:7:::
daemon:*:10933:0:99999:7:::

The first two fields are the username and the password hash. The remaining seven are related to password aging, which is not usually an issue on embedded devices. If you are curious about the full details, refer to the manual page shadow(5).

In the example, the password for root is empty, meaning that root can log on without giving a password, which is useful during development, but not for production! You can generate a password hash by using the command mkpasswd or by running the passwd command on the target and copy and pasting the hash field from /etc/shadow on the target into the default shadow file in the staging directory.

The password for daemon is *, which will not match any logon password, once again ensuring that the daemon cannot be used as a regular user account.

Group names are stored in a similar way in /etc/group. The format is as follows:

  • The name of the group
  • The group password, usually an x character, indicating that there is no group password
  • The GID
  • An optional list of users who belong to this group, separated by commas.

Here is an example:

root:x:0:
daemon:x:1:

Adding user accounts to the root filesystem

Firstly, you have to add to your staging directory etc/passwd, etc/shadow, and etc/group, as shown in the preceding section. Make sure that the permissions of shadow are 0600.

The login procedure is started by a program called getty, which is part of BusyBox. You launch it from inittab using the keyword respawn, which restarts getty when a login shell is terminated, so inittab should read like this:

::sysinit:/etc/init.d/rcS
::respawn:/sbin/getty 115200 console

Then rebuild the ramdisk and try it out using QEMU or BeagelBone Black as before.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.191.237.79