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.
Could they be changing the root password by performing a password reset procedure outside of the installed operating system?
If that's the case, you dont have much protection because physical access trumps everything.
In this case, you're better off establishing an office policy (and consequences) about circumventing established security controls. At that point, it would be trivial to setup a scheduled task to check the machines from time to time and verify the password has not been compromised/changes.
You could disable cdrom & usb booting in BIOS. Then password protect bios and grub so that a password is needed to choose a non-default grub option, or the grub menu. I think this also protects against adding "init=/bin/bash" to the kernel entry in grub. Locked down this way, the user would have to pop open the case and drain the bios memory.
No, there is nothing you can do to prevent this type of action when there is no control over physical access.
Create a policy document that states circumvention of security controls is a violation of employment and can result in disiplinary action including termination. Make all employees read and sign the document and add it to their file. Then create a scheduled task to routinely connect to all the workstations in question and test that the password has not been tampered with.
I'll just expand on that "no" that Admiral Beotch is talking about.
You can block resetting the root password by single user mode by passwording grub, however then they can go back and reinstall grub and thus get a new unpassworded grub. You can then password BIOS but then they can do a CMOS reset. Effectively the only way to block them being able to do this, is to lock the computers in big metal boxes that are locked. Those aren't free and do block off the CD/DVD drive, so you'd need external DVD drives going into the cases and you'd have to secure them so no body tries to steal the externals. So It's possible to stop them being able to reset the password but the lenghts you have to go to are a bit crazy.
I would suggest making it clear they are not allowed to use root privilages, reset the root passwords and clean out the sudoers file. Then you can place in roots .bashrc a link to a small script that sends a message of some sort whenever somebody logins as root and what machine they have done it on. Then you can displine them on this behaviour, they will be less likely to do it if they actually get into serious trouble for it.
my problem is ... user just use Linux single command in boot prompt and change the root password.
is there any way to block this problem?
If it's a computer you control, put a bios password on the system, and install a case lock... anytime it reboots they have to ask you for the password. Shy true physical control, there is nothing you can do to prevent them from doing a bios reset, booting into single user mode, and changing the password. Physical access trumps all that isn't physical.
At work, there are some rooms with equipment where a FOB is needed for access. It grants access and the use of a FOB is logged, adding accountability. One of these is the telephony room. If you have an important server, than you should restrict access to it.
You can lock down grub so that they can't boot into the single mode without a password. For servers, some admins pull the cable to the cdrom/dvdrom drive. Mostly so that a bad cdrom or DVD doesn't cause a slowdown, but also to prevent booting to it, or simply forgetting to remove it & causing problems it the server reboots.
We had a server previously that used a raid-5 array for the filesystem. There was a smallish ide drive installed but disabled in the bios. If there was a SCSI problem and the raid array wasn't bootable, enabling it in bios & booting to it would give you service tools.
You could do something similar.
Please read the grub howto in the www.tldp.org website. Locking down grub should prevent adding boot options such as booting into single user mode.
Or you could just reinstall grub, after you reset the CMOS and get your BIOS password removed. Locking down grub will only really stop only the most amateur. Really the only catchall fix is put you box in a safe...
or you can install an atmel chip, store the password in it, it will only give up it's data through a physical connection using a modified serial port adapter. that is how IBM stores it's passwords on the thinkpads. removing cmos battery will not reset the password.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.