It sounds like you already know enough to choose a permission design for /home/user1, or equivalent. You're asking about the rest of the system. There are already a few discussions here, at least on a related topic:
remove all permissions, except x, of group and others for /etc, /usr folders. But what about other folders like /usr, /var etc
Looking at the Unix DAC permissions on system directories, and making them more restrictive than the provided defaults, is not a common tactic. (With the exception of permissions on user's home directories. There is usually a configuration setting for this). The only way to answer a question as broad as -
how design permissions in root file system should look
- is that you should use the standard DAC permissions for system directories. You chould check against your favourite Linux distribution if you like. You could also look at the FHS, although that may lack a few recent updates.
Getting into buildroot specifically might make it more feasible to change them. But that does not mean you that you "should"!
I would like to have safe root group (no extra privileges), since it may be accessed with usermod -aG root someone by admin.
Not recommended. You cannot allow unrestricted useradd, because of useradd -u 0, so you need wrapper scripts or something anyway. (E.g. set sudoers to allow admin to run the wrapper script as root). Better e.g. provide a wrapper script for usermod as well, and do your protection in the script. Then you can prevent attacking other non-root "system" groups (daemon accounts) as well.
"ordinary users" (beside www-data) may login using ssh.
It looks like you're trying to run a secure multi-user Unix-like system. That's the most important part of the question.
That general problem is too broad, to ask here and get a definitive answer.
If the users are completely untrustworthy, the honest answer is that you cannot. There are various tradeoffs, strategies and tactics.
The question is really not specific to "embedded device, with busybox onboard (buildroot environment)". Except that this might narrow down which tactics are easily available to you.
Specifically, note that using buildroot is going to make it a lot more work to implement security updates, compared to standard binary distributions like Debian Linux.
Out of the possible free software distributions you could look at, I am very sceptical that buildroot is aiming for highly secured multi-user Linux systems :-). (Either multi-user network servers, used in universities and some similar environments, or multi-user PCs).
Most large organizations have similar problems with internal multi-user systems. But the simplest approach they use is to not run any one large multi-user Unix (or Windows :-) instance, that users can actually run programs on!
The common case like this is actually where you have desktop PCs that can be used by different workers ("hot-desking", or just multiple shifts). Some of the common controls here are key parts of Microsoft' business model ("Group Policy") or the wider Windows ecosystem, and some are not available as free software equivalents.
One of the most powerful controls is "application whitelisting". Providing the user with a full programming / scripting environment, like the Unix shell, is a relatively high risk. It is often not needed. (And systems can absolutely be engineered to deny access to them).
I'm afraid of busybox binary, since it has set-uid bit turned on
A few of the busybox applets are standard commands that can require setuid root to work as expected. This is designed to be secure, and officially supported.
config FEATURE_SUID
bool "Drop SUID state for most applets"
default y
help
With this option you can install the busybox binary belonging
to root with the suid bit set, enabling some applets to perform
root-level operations even when run by ordinary users
(for example, mounting of user mounts in fstab needs this).
With this option enabled, busybox drops privileges for applets
that don't need root access, before entering their main() function.
If you are really paranoid and don't want even initial busybox code
to run under root for every applet, build two busybox binaries with
different applets in them (and the appropriate symlinks pointing
to each binary), and only set the suid bit on the one that needs it.
Some applets which require root rights (need suid bit on the binary
or to be run by root) and will refuse to execute otherwise:
crontab, login, passwd, su, vlock, wall.
The applets which will use root rights if they have them
(via suid bit, or because run by root), but would try to work
without root right nevertheless:
findfs, ping[6], traceroute[6], mount.
Note that if you DO NOT select this option, but DO make busybox
suid root, ALL applets will run under root, which is a huge
security hole (think "cp /some/file /etc/passwd").
