A post made in the LEAP 42.2 thread “Executing Dolphin as root is not possible.” <https://forums.opensuse.org/showthread.php/524150-Executing-Dolphin-as-root-is-not-possible> has prompted this thread.
ajohnw:
Why the Ubuntu doesn’t have a root password. but I suppose the user one would do.
I must admit I have been concerned about malware ever since I started running Linux. I had seen lots of variations on ms,. even some on my own machine. I personally would be happier if any change on my machine not due to me required me to provide a password who ever or where ever the change was coming from. I’d include updates in that as well. There shouldn’t be any mechanism for hiding a user on a machine really and if there is one it should be very obvious. That just leaves free software problems (on ms anyway) where if it’s useful and not os people are very likely to get something the don’t really want or need buried in it somewhere.
First:
The user “root” and the associated password:
- Yes, by default Ubuntu locks the password of the user “root” and, that password is empty.
It seems however that, Ubuntu doesn’t set the login shell of the user “root” to either ‘/bin/false’ or ‘/usr/sbin/nologin’.
- Ubuntu also has an administrative “sudo” user for administration tasks;
such as setting up a password for the user “root” and unlocking the password of the user “root”.
As discussed in the “Executing Dolphin as root is not possible.” thread, it is possibly a good idea to setup (with the user “root”) some administrative user accounts for the more mundane system administration tasks and, once the administrative users have been set up, to avoid logging in as “root”.
- At a minimum, the user “root” should never be available via remote login – for “heavy” system administration, the root login should be confined to the physical system console physically attached to the system.
[HR][/HR]Second: Malware:
Unwanted, destructive, damaging, data collecting, thieving, spying, snooping, applications normally, can only be introduced into a system if, a system administrator or a user has a (network or, device) channel open to the source which attempts to introduce such applications into the system.
- If the channel (network or device, for example a USB-Stick) isn’t open then, the “bad” application can not be introduced to the system.
In other words, system administrators shouldn’t use accounts which were used for network activities and, the system administrator’s directories have to be audited for unwanted/unauthorised files . . .
In the case of “normal” users, we’re out of luck – “normal” users will introduce Malware into the system but, the scope of any damage done as a result, has to be constrained by the privileges assigned to each and every “normal” user. The constraints which can be imposed by user groups should also be considered.
Let’s take the case of the file “/etc/passwd”:
- Each and every user on the system can read this file.
- The file contains information related to users who are local to the system.
- If the “normal” users, and the administrators, are all verified by means means of a LDAP server then, “/etc/passwd” contains only “boring” information about local system pseudo-users with disabled logins.
[HR][/HR]OK. That’s my two pennies worth – now it’s up to the forum community to add to the picture.