[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Restrict root access

Valid point. There might be a solution for that.

What about adding a new user admin?

Long term version:

  • user user not being member of group sudo / su etc.
  • Users are advised to login as user admin and then use sudo.

At first, this could be a documentation-only thing for advanced users. (This could be implemented very soon.)

Not sure the cumbersomeness usability wise would allow this to ever become a default configuration.


Very long term version:

  • wayland will sort the need to login using a virtual console.

So until we have a solution for that (realistically only wayland in many years most likely), I think we should go for virtual console login. At least as security advice for advanced users.

1 Like

That sounds great although having to login from a virtual console every time a user wants to run a command as root sounds cumbersome.

For a default configuration we could restrict root so only the user user can run su and sudo and root can only be logged in via something like tty1. This way, there won’t be much of a usability decrease while also having protection from any user gaining root via su or sudo.

2 Likes

Indeed cumbersome.

(Documentation could also be the other way around. User user having sudo access by default and recommending advanced users to create a new user limited and use that for non-root acclivities such as browsing, chatting, etc. Also disable user user auto login then. And advice to not enter sudo password anywhere but in a virtual console. An optional script setting this up for better usability could be provided. - Disadvantage: username being user is a privacy feature since shared among all Whonix users in case it leaks.)

It’s ok to change your opinion but I would like to understand. Why did you change your position compared to the original threat in this post? [In case you did?]

Why leave tty1 root login possible while blocking tty2, tty3, etc.?

1 Like

I didn’t. I would prefer to have root restricted as much as possible but that would be a huge decrease in usability so it would be best to restrict it as much as possible without decreasing usability much as a default configuration.

It reduces the amount of ways an attacker can login as root to just one and reduces attack surface. If you look inside /etc/securetty there are many places you can login as root. I don’t even know what a lot of them are.

2 Likes

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s2-wstation-privileges-noroot.html

(https://web.archive.org/web/20171207012252/https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s2-wstation-privileges-noroot.html)

1 Like

No root login -> user only needs to remember and secure one password.

related:

Thanks for elaborate explanation!

Could you implement this please?

1 Like

Which parts should be implemented? Should the user user be able to use su? Should the root account be locked?

1 Like

All. As in original post. (Hence I made an almost full quote.)
Please also document each change so those who don’t like it can reverse it.

Yes, I see no reason against that yet. user user should be able to use sudo, sudo su. When that works, not sure if “standalone” (no sudo) su is still required. Please let me know if blocking su given us further hardening under which threat model.

sudo passwd -l root and/or setting login shell to /sbin/nologin? Either, or? Or both advisable?

Where would that be implemented? In https://github.com/Whonix/anon-base-files/blob/master/debian/anon-base-files.postinst?

1 Like

Setting the login shell to /sbin/nologin won’t help much. You can still run sudo -u root bash and get shell access. We could implement both but I’m not sure how. I highly doubt there is a passwd.d.

That sounds like the best way.

1 Like

/etc/pam.d/passwd contains nothing except an include rule for /etc/pam.d/common-password so I edited that instead.

I created a pull request for all these.

2 Likes

And after that I just merged that I got a different version on my system due to another package. Contents in /etc/pam.d are influences through a mechanism using configuration drop-in folder /usr/share/pam-configs/. So config-package-dev is quite possibly the wrong approach to implement (most) of our pam changes. Could you look into this please?

1 Like

Those files have weird formatting.

user@host:~$ cat /usr/share/pam-configs/mkhomedir 
Name: Create home directory on login
Default: no
Priority: 0
Session-Type: Additional
Session-Interactive-Only: yes
Session:
	optional	pam_mkhomedir.so

There’s a section on the Ubuntu wiki that might be useful.

https://wiki.ubuntu.com/PAMConfigFrameworkSpec

I’m not sure how this could be implemented.

1 Like

There are two folders:

  • /usr/share/pam
  • /usr/share/pam-configs
1 Like

/usr/share/pam just seems to duplicate some files from /etc/pam.d and give md5 hashes of them.

1 Like

madaidan via Whonix Forum:

/usr/share/pam just seems to duplicate some files from /etc/pam.d and give md5 hashes of them.

Duplicate might be an understatement. /usr/share/pam looks to be the
template from which /etc/pam.d is build and then supplemented with
/usr/share/pam-configs.

Also /usr/sbin/pam-auth-update is involved. But also some other tool
much be involved since I did not see yet what reads from /usr/share/pam.

Our current implementation of changing /etc/pam.d directly using
config-package-dev seems really bad, breaking the usual mechanism for
populating that folder. Not fit for release since hard to later move
back to the proper mechanism, also breaking things for any user/package
using the standardized pam-auth-update mechanism.

1 Like

We could make a script that appends the needed lines to the existing files but that seems a bit hacky.

1 Like

Really hacky indeed. We first need to understand and exhaust the usual mechanism which all other pam related packages are using (as mentioned above). There are a ton of packages interacting with pam in a proper way.

https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=libpam

2 Likes

If you look at the list of files in the packages, you can see that some of those packages are using /usr/share/pam-configs or are putting their module directly in /lib/security.

/usr/share/pam-configs seems to be the best way.

2 Likes
1 Like
1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]