Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Stumped on this one. I'm trying to set up limited sudo authority on a desktop with some sensitive user data, and as an extra precaution I wanted to configure sudo to use a password other than the user's or the root's. I'm not sure how to do this. From the manual, we have a few options, such as "runaspw" or "targetpw", but none seem quite what I'm looking for.
For instance, "runaspw" could be used if I created a user for nothing other than sudo(ing) purposes, but it requires you set "runas_default", which means that said user would have to have authority to execute said commands in the first place. This is workable, but seems like a lot of extra configuration for each specific command that I want to run, as well as creating some issues with simply commands such as "shutdown" or "reboot". Also, "targetpw" can be used in conjunction with a sudo(ing)-only user if I set an alias, but, again, this isn't quite what I am looking for.
Ultimately, what I am really concerned about in this situation are keystroke loggers, so I would prefer to avoid repeated entering the user or root password when performing administrative tasks. Also, I would prefer not having to create a sudo(ing)-only user as mentioned above to prevent a comprimised password resulting in an attacker being able to log into my system.
Most of what you say is beyond me, but you can make a user account that cannot login by setting their login shell appropriately. Some distros provide /sbin/nologin (like RHEL) which spits out a message saying login isn't allowed. Others tend to use /bin/false.
Usually that's used for things like samba-only users, but it might work for what you want to do.
Most of what you say is beyond me, but you can make a user account that cannot login by setting their login shell appropriately. Some distros provide /sbin/nologin (like RHEL) which spits out a message saying login isn't allowed. Others tend to use /bin/false.
Usually that's used for things like samba-only users, but it might work for what you want to do.
That was something I was considering, and might be the best solution. But as you said, there is the ssh issue. And there are god-knows what other exploits I'm not even aware of. But thank you for the response, this might be what I end up implementing if there are no better options.
Nevermind, the "targetpw" with sudo -u idea won't work. I don't know what I was thinking, but the -u option means run as user, which puts be back in the same place of setting some complex user permissions.
No other ideas on this one? Along with some restrictions on what commmands can be used, this seems like a simple way to greatly increase the security of sudo.
Maybe I should Mr. Miller and see if he would consider adding this feature.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.