Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 04:48:36PM +0300, Reco wrote:
I just like to remind you the original question:
Is there a way to put an account "beyond use", in any way including su,
sudo etc,
*In any way* includes the way I've described above IMO.
So you're asking if there's a way to prevent someone from using sudo to
do something sudo has been specifically configured to do? Kind of a
weird question, IMO. If you don't want to allow someone to sudo to a
particular user then...don't configure sudo to allow them to do that.
Also worth pointing out that having a passwd entry isn't even relevant
to whether root can setuid. At some point if you've provided enough rope
then setting a bunch of artificial constraints for the sake of argument
is just a waste of time.
# id
uid=0(root) gid=0(root) groups=0(root)
# id 1234
id: ‘1234’: no such user
# python3 -c 'import os; os.setuid(1234); os.execl("/bin/bash", "bash")'
$ id
uid=1234 gid=0(root) groups=0(root)
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 10:42:36AM -0500, Greg Wooledge wrote: In the context of the original question, having a consistent set of local user accounts (name/UID pairs) across all of your systems in an NFS environment is useful for making sure all files have consistent ownership. Even on the systems where, say, charlie will never log in, seeing that the files in /home/charlie are owned by user "charlie" is helpful. It's practically impossible to sync everything on a modern system in the presence of dynamically allocated IDs. The best you can hope for is sync a certain *range* of IDs and by convention only use IDs in that range within NFS exports. If something outside that range happens to sneak into the export it'll look weird, but has no real effect on security. (If you're using sec=sys on an NFS mount you have no security outside of what the client chooses to implement.) Historically this could be done by being diligent in manually creating passwd entries, via yp/nis to distribute a common passwd file, or via various configuration management schemes to automate local passwd file management. In most normal (heterogenous) environments these did only manage a certain range, and trying to sync system users was simply not done because it was harder than it was worth.
Re: Permissions on NFS mounts
On Wed, Dec 09, 2020 at 03:38:21PM -0500, Paul M Foster wrote: I have two users on the client: paulf 1000 and nancyf 1001. On the server, I have two users: pi 1000 and paulf 1001. I can mount the NFS share from the server to /mnt on my client. But any files belonging to me (user 1001 on the server) look like they belong to nancy (user 1001 on the client. More importantly, if I copy files to this share from the client, they will look like they belong to pi (user 1000) on the server. Is there some way in the /etc/exports file to adjust the parameters so that files retain my ownership on the server? Traditional NFS depends on the uid/gid matching across all the systems in a tightly controlled local network. Your solution involves changing the IDs so they match. The newer model for NFS depends on cryptographic authentication (generally kerberos) of requests rather than assuming that everything is trusted and consistently configured. In this model you can have the uid/gid be random, but you need a kerberos server. It is theoretically possible to do uid mapping without the authentication component, but that's all disabled by default and I'm not sure how current any of the directions or even the code is. You'd need to set up static maps in /etc/idmapd.conf and set nfs4_disable_idmapping=0 on the nfsd module. Also make sure you're using nfs4 and not nfs3. "idmapd.conf" and "nfs4_disable_idmapping" should be good google keywords to find instructions. Depending on your use case you might also find running samba and using cifs rather than nfs works better for you. (Or not.) It has a different authentication model and interface with its own pros and cons.
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 03:35:50PM +, Tixy wrote: > Why would you execute sudo or su on the target machine to change to one > of these unneeded users, presumably you can do whatever mischief is > your aim by using the account you are executing su or sudo from. Or by > changing to another valid user on that machine if you are a legitimate > user and were trying to cover your tracks. If you have full sudo access, you're *already* at the top of the food chain. You can create a new user and switch to it. You can delete users. You can lock and unlock users. You can do literally everthing, because you're the superuser. Putting additional entries in the passwd file is not a security issue, unless those entries have guessable passwords, or some other means of logging in as them from a remote system, or from a different non-root user account. Additional entries in passwd are useful for *lots* of things, such as running a service as a UID that has no other access. They are not a reduction in security. Properly used, they can increase security. In the context of the original question, having a consistent set of local user accounts (name/UID pairs) across all of your systems in an NFS environment is useful for making sure all files have consistent ownership. Even on the systems where, say, charlie will never log in, seeing that the files in /home/charlie are owned by user "charlie" is helpful.
Re: Permissions on NFS mounts
On Thu 10 Dec 2020 at 16:48:36 (+0300), Reco wrote: > On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > > At least on Debian sudo has to be explicitly configured to allow a > > regular user to use '-u' with another user name. We can only assume the > > admin had good reasons to that, possibly on purpose (see below). > > You're correct here, one has to explicitly allow such activity in > sudoers in Debian and just about any OS I've encountered these years > (assuming it has sudo, of course). > > I just like to remind you the original question: > > Is there a way to put an account "beyond use", in any way including su, > sudo etc, > > *In any way* includes the way I've described above IMO. The original question was almost a textbook example of the X Y problem. The opening statement says "you'll inevitably end up with situations where users are created on some of the machines only for the purpose of keeping the IDs in synch", and that's wrong. So why try to solve it. Fortunately, this statement reveals X (which would be unreported in a true textbook example). Your reminder of the "original question" just quotes part of Mark's attempted solution to problem Y, namely creating an account that's barred. The answer to the real "original question" is to avoid creating those accounts at all—then there's no need to bar them. Cheers, David.
Re: Permissions on NFS mounts
On Thu, 2020-12-10 at 16:48 +0300, Reco wrote: > On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > > On Jo, 10 dec 20, 13:34:55, Reco wrote: > > > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU > > > > > wrote: > > > > > > passwd -l/--lock > > > > > > > > > > sudo -u /bin/bash -i > > > > > > > > > > That little trick defeats "locked" account status, an absence > > > > > of a > > > > > password and even /usr/sbin/nologin set as a default shell. > > > > > > > > With sudo access one can also unlock the account as well, so > > > > how is this > > > > relevant? > > > > > > Of course it's relevant. The whole point of sudo is to be a > > > controlled > > > privilege escalation mechanism. > > > I.e. you can grant an ordinary user A to execute a certain > > > binaries with > > > certain arguments as a different ordinary user B, *and* you do > > > not have > > > to provide an ordinary user A an access to root. > > > > At least on Debian sudo has to be explicitly configured to allow a > > regular user to use '-u' with another user name. We can only assume > > the > > admin had good reasons to that, possibly on purpose (see below). > > You're correct here, one has to explicitly allow such activity in > sudoers in Debian and just about any OS I've encountered these years > (assuming it has sudo, of course). > > I just like to remind you the original question: > > Is there a way to put an account "beyond use", in any way including > su, > sudo etc, Which, IMO, is a rather bogus question in the context that preceded that question, namely "having unneeded users on a given machine could be a security threat, at least in the sense that it provides a greater than necessary attackable surface area" Why would you execute sudo or su on the target machine to change to one of these unneeded users, presumably you can do whatever mischief is your aim by using the account you are executing su or sudo from. Or by changing to another valid user on that machine if you are a legitimate user and were trying to cover your tracks. -- Tixy
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 03:36:47PM +0200, Andrei POPESCU wrote: > On Jo, 10 dec 20, 13:34:55, Reco wrote: > > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > > > > > passwd -l/--lock > > > > > > > > sudo -u /bin/bash -i > > > > > > > > That little trick defeats "locked" account status, an absence of a > > > > password and even /usr/sbin/nologin set as a default shell. > > > > > > With sudo access one can also unlock the account as well, so how is this > > > relevant? > > > > Of course it's relevant. The whole point of sudo is to be a controlled > > privilege escalation mechanism. > > I.e. you can grant an ordinary user A to execute a certain binaries with > > certain arguments as a different ordinary user B, *and* you do not have > > to provide an ordinary user A an access to root. > > At least on Debian sudo has to be explicitly configured to allow a > regular user to use '-u' with another user name. We can only assume the > admin had good reasons to that, possibly on purpose (see below). You're correct here, one has to explicitly allow such activity in sudoers in Debian and just about any OS I've encountered these years (assuming it has sudo, of course). I just like to remind you the original question: Is there a way to put an account "beyond use", in any way including su, sudo etc, *In any way* includes the way I've described above IMO. > > Also, passwd(1): > > > > -l, --lock > >Note that this does not disable the account. The user may still > > be able to login using another authentication token (e.g. an SSH key). > > To disable the account, administrators should use usermod --expiredate 1 > > (this set the account's expire date to Jan 2, 1970). Users with a > > locked password are not allowed to change their password. > > As I said, there are limitations, that may or may not be desired, e.g. > I'm using the SSH access option, because 'systemctl --user' doesn't work > via 'sudo -u' (and it's a remote system anyway). It can, it's just inconveniencely (sp?) annoying. I.e. you have to make sure that dbus-daemon is running as a target user and you have to set DBUS_SESSION_ADDRESS to a right value, and about the only way to get that right value is to look at /proc//environ. Whoever thought it's a good idea to couple systemctl and dbus deserves something really bad happening to them. Reco
Re: Permissions on NFS mounts
On Jo, 10 dec 20, 13:34:55, Reco wrote: > On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > > > passwd -l/--lock > > > > > > sudo -u /bin/bash -i > > > > > > That little trick defeats "locked" account status, an absence of a > > > password and even /usr/sbin/nologin set as a default shell. > > > > With sudo access one can also unlock the account as well, so how is this > > relevant? > > Of course it's relevant. The whole point of sudo is to be a controlled > privilege escalation mechanism. > I.e. you can grant an ordinary user A to execute a certain binaries with > certain arguments as a different ordinary user B, *and* you do not have > to provide an ordinary user A an access to root. At least on Debian sudo has to be explicitly configured to allow a regular user to use '-u' with another user name. We can only assume the admin had good reasons to that, possibly on purpose (see below). It's probably unpractical to consider all ways in which the admin can compromise the security of the system. > Also, passwd(1): > > -l, --lock > Note that this does not disable the account. The user may still > be able to login using another authentication token (e.g. an SSH key). > To disable the account, administrators should use usermod --expiredate 1 > (this set the account's expire date to Jan 2, 1970). Users with a > locked password are not allowed to change their password. As I said, there are limitations, that may or may not be desired, e.g. I'm using the SSH access option, because 'systemctl --user' doesn't work via 'sudo -u' (and it's a remote system anyway). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Permissions on NFS mounts
On 10/12/2020 09:10, Mark Fletcher wrote: > On Wed, Dec 09, 2020 at 03:54:10PM -0500, Dan Ritter wrote: >> Paul M Foster wrote: >>> I have two users on the client: paulf 1000 and nancyf 1001. On the >>> server, I have two users: pi 1000 and paulf 1001. I can mount the NFS >>> share from the server to /mnt on my client. But any files belonging to >>> me (user 1001 on the server) look like they belong to nancy (user 1001 >>> on the client. More importantly, if I copy files to this share from the >>> client, they will look like they belong to pi (user 1000) on the server. >>> >>> Is there some way in the /etc/exports file to adjust the parameters so >>> that files retain my ownership on the server? >> You're looking for userid mapping, handled by idmapd. >> >> Your best long-term solution is to make the userids consistent >> across machines by making a decision about who will be 1000, >> 1001 and 1002, and then changing /etc/passwd and running >> suitable "chown -R" commands, probably followed by find >> commands. >> >> Debian automatically starts user numbering at 1000, so it's a >> good idea to have a consistent install username, if you can >> arrange it. >> > > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines > only for the purpose of keeping the IDs in synch so they can all play > nice with the NFS. Left alone, having unneeded users on a given machine > could be a security threat, at least in the sense that it provides a > greater than necessary attackable surface area. What can be done about > that? Obviously one thing would be setting the shell to /dev/null in the > password file of those machines that don't need a given user, to prevent > interactive logins. What else could be done? Is there a way to put an > account "beyond use", in any way including su, sudo etc, while still > having the machine recognise the user for being a user and therefore not > messing up the mapping of user IDs on shared resources like NFS? In > other words, create the sense of "yes this user exists, but they are not > welcome here"? If you're getting to the stage of managing multiple users over multiple machines, then you probably want to look at a central identity management solution. That could be as simple as NIS, or OpenLDAP or if you things a bit more "boxed up", FreeIPA. I have several computers (a mixture of physical and virtual) at home and just two humans, but FreeIPA allows us to define our users once (username/password/etc) and have that user able to log onto any FreeIPA-joined PC. Users can be added to groups, they can even be granted permissions using the RBAC and HBAC capabilities of FreeIPA (Role- and Host-base Access Control). OpenPGP_signature Description: OpenPGP digital signature
Re: Permissions on NFS mounts
On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > passwd -l/--lock > > > > sudo -u /bin/bash -i > > > > That little trick defeats "locked" account status, an absence of a > > password and even /usr/sbin/nologin set as a default shell. > > With sudo access one can also unlock the account as well, so how is this > relevant? Of course it's relevant. The whole point of sudo is to be a controlled privilege escalation mechanism. I.e. you can grant an ordinary user A to execute a certain binaries with certain arguments as a different ordinary user B, *and* you do not have to provide an ordinary user A an access to root. Also, passwd(1): -l, --lock Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's expire date to Jan 2, 1970). Users with a locked password are not allowed to change their password. Reco
Re: Permissions on NFS mounts
On Jo, 10 dec 20, 12:52:56, Reco wrote: > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > passwd -l/--lock > > sudo -u /bin/bash -i > > That little trick defeats "locked" account status, an absence of a > password and even /usr/sbin/nologin set as a default shell. With sudo access one can also unlock the account as well, so how is this relevant? As I already hinted, the 'locked' status has another limitation that may or may not be desired, depending on use case. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Permissions on NFS mounts
Hi. On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > Left alone, having unneeded users on a given machine could be a > > security threat, at least in the sense that it provides a greater than > > necessary attackable surface area. What can be done about that? > > Obviously one thing would be setting the shell to /dev/null in the > > password file of those machines that don't need a given user, to > > prevent interactive logins. What else could be done? Is there a way to > > put an account "beyond use", in any way including su, sudo etc, while > > still having the machine recognise the user for being a user and > > therefore not messing up the mapping of user IDs on shared resources > > like NFS? In other words, create the sense of "yes this user exists, > > but they are not welcome here"? > > passwd -l/--lock sudo -u /bin/bash -i That little trick defeats "locked" account status, an absence of a password and even /usr/sbin/nologin set as a default shell. Reco
Re: Permissions on NFS mounts
Hi. On Thu, Dec 10, 2020 at 09:10:42AM +, Mark Fletcher wrote: > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines > only for the purpose of keeping the IDs in synch so they can all play > nice with the NFS. But why? useradd has "-u" flag for ages, all that's required is to supply an appropriate number for uid. You just create user(s) which are supposed to be on this host with the needed uid (maybe - gids), and do not create those you don't need. > Left alone, having unneeded users on a given machine > could be a security threat, at least in the sense that it provides a > greater than necessary attackable surface area. What can be done about > that? Obviously one thing would be setting the shell to /dev/null in the > password file of those machines that don't need a given user, to prevent > interactive logins. Current fashion is to use /usr/sbin/nologin for such accounts. But that's solving the problem one should not have in the first place. As for sudo and others - there's only proper one solution for such "unwelcome" users, and it's called userdel. Reco
Re: Permissions on NFS mounts
On Jo, 10 dec 20, 09:10:42, Mark Fletcher wrote: > > This brings up an interesting thought. In the situation where you align > user IDs across a number of machines for ths purpose, you'll inevitably > end up with situations where users are created on some of the machines > only for the purpose of keeping the IDs in synch so they can all play > nice with the NFS. adduser --uid 1234 As far as I know the user creation step can be skipped in the Debian Installer, if for any reason uid 1000 is to remain unallocated, otherwise just use debootstrap/mmdebstrap instead. > Left alone, having unneeded users on a given machine could be a > security threat, at least in the sense that it provides a greater than > necessary attackable surface area. What can be done about that? > Obviously one thing would be setting the shell to /dev/null in the > password file of those machines that don't need a given user, to > prevent interactive logins. What else could be done? Is there a way to > put an account "beyond use", in any way including su, sudo etc, while > still having the machine recognise the user for being a user and > therefore not messing up the mapping of user IDs on shared resources > like NFS? In other words, create the sense of "yes this user exists, > but they are not welcome here"? passwd -l/--lock See 'man passwd' for details, limitations and alternatives. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Permissions on NFS mounts
On Wed, Dec 09, 2020 at 03:54:10PM -0500, Dan Ritter wrote: > Paul M Foster wrote: > > I have two users on the client: paulf 1000 and nancyf 1001. On the > > server, I have two users: pi 1000 and paulf 1001. I can mount the NFS > > share from the server to /mnt on my client. But any files belonging to > > me (user 1001 on the server) look like they belong to nancy (user 1001 > > on the client. More importantly, if I copy files to this share from the > > client, they will look like they belong to pi (user 1000) on the server. > > > > Is there some way in the /etc/exports file to adjust the parameters so > > that files retain my ownership on the server? > > You're looking for userid mapping, handled by idmapd. > > Your best long-term solution is to make the userids consistent > across machines by making a decision about who will be 1000, > 1001 and 1002, and then changing /etc/passwd and running > suitable "chown -R" commands, probably followed by find > commands. > > Debian automatically starts user numbering at 1000, so it's a > good idea to have a consistent install username, if you can > arrange it. > This brings up an interesting thought. In the situation where you align user IDs across a number of machines for ths purpose, you'll inevitably end up with situations where users are created on some of the machines only for the purpose of keeping the IDs in synch so they can all play nice with the NFS. Left alone, having unneeded users on a given machine could be a security threat, at least in the sense that it provides a greater than necessary attackable surface area. What can be done about that? Obviously one thing would be setting the shell to /dev/null in the password file of those machines that don't need a given user, to prevent interactive logins. What else could be done? Is there a way to put an account "beyond use", in any way including su, sudo etc, while still having the machine recognise the user for being a user and therefore not messing up the mapping of user IDs on shared resources like NFS? In other words, create the sense of "yes this user exists, but they are not welcome here"? Mark
Re: Permissions on NFS mounts
Paul M Foster wrote: > I have two users on the client: paulf 1000 and nancyf 1001. On the > server, I have two users: pi 1000 and paulf 1001. I can mount the NFS > share from the server to /mnt on my client. But any files belonging to > me (user 1001 on the server) look like they belong to nancy (user 1001 > on the client. More importantly, if I copy files to this share from the > client, they will look like they belong to pi (user 1000) on the server. > > Is there some way in the /etc/exports file to adjust the parameters so > that files retain my ownership on the server? You're looking for userid mapping, handled by idmapd. Your best long-term solution is to make the userids consistent across machines by making a decision about who will be 1000, 1001 and 1002, and then changing /etc/passwd and running suitable "chown -R" commands, probably followed by find commands. Debian automatically starts user numbering at 1000, so it's a good idea to have a consistent install username, if you can arrange it. -dsr-
