asked on
Access Required to Read Linux Security Settings and User Permissions
I want to create a service account that can connect to a Linux operating system and read the following:
- Users' permissions (Read, Write, etc.) to certain directories - not just for the service account but for ALL users;
- Log on settings like Password Length, Password Complexity, and Maximum Logon Failures.
It is really important for this service account to have as little access to change, delete, or create data as possible. Ideally, It would be Read access.
What is the minimum access permissions the service account will need to be able to do this?
I am obviously not a Linux expert. If the service account needs to be an Admin to do this, is there some way to restrict the access of an Admin account to disable its ability to change, delete, and create data on the Linux operating system
- Users' permissions (Read, Write, etc.) to certain directories - not just for the service account but for ALL users;
- Log on settings like Password Length, Password Complexity, and Maximum Logon Failures.
It is really important for this service account to have as little access to change, delete, or create data as possible. Ideally, It would be Read access.
What is the minimum access permissions the service account will need to be able to do this?
I am obviously not a Linux expert. If the service account needs to be an Admin to do this, is there some way to restrict the access of an Admin account to disable its ability to change, delete, and create data on the Linux operating system
Linux SecurityLinuxUnix OS
Last Comment
humbleamateur
You are asking for information that is restricted to the root Superuser. Secondly, you're asking for information that is extremely susceptible to abuse from a hacker. To the best of my knowledge, then, the answer to your question is no. Search access is restricted to root as the authorized privileged user.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
I read the question as though it were generic. The asker wants a method to come into a system virtually undetected.
It seems more like an audit point but I agree. This is normally a check that's run by root. And the password complexity cannot necessarily be determined by looking at the crypt password.
I meant to point out: the passwords in /etc/shadow are more strongly encrypted than /etc/passwd used to be. That's why you can't tell how long or simple the original password was except if it cracks easily.
ASKER
Yes, this was a thought on automating some auditing of servers.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
If you have time, do a web search on the Defense Information Systems Agency, or DISA. Read up on their STIGS.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
While it is true that you can set restrictions on the "general populace", another tenet of Unix (and Linux) is that root can do almost anything -- including overriding the password limits.
But I do agree that for audit requirements, you can use the system settings to demonstrate that password restrictions / complexity enforcement are in place. Still, for someone who has done security audits on Linux systems for many MANY years, I can't tell you how many times I've audited systems that had perfectly good, secure settings for users, but the root password was incredibly simple (and well known to many users).
Never the less, the author never stated a purpose for his inquiry, and I made no assumptions. Perhaps I read into the question that he wanted to see CURRENT PASSWORD complexity, length, and other characteristics... if so, my bad.
FWIW: The idea of keeping passwords in such a way as even admins cannot see the passwords is a GOOD one -- if you don't believe me, ask the admins over at DropBox -- where they just lost some 68+ million passwords to a hack... but they're all hashed! And compare their level of worry with those of Linked-IN -- who is trying to manage the loss of 100+ million actual passwords (stored in clear text!).
Dan
IT4SOHO
But I do agree that for audit requirements, you can use the system settings to demonstrate that password restrictions / complexity enforcement are in place. Still, for someone who has done security audits on Linux systems for many MANY years, I can't tell you how many times I've audited systems that had perfectly good, secure settings for users, but the root password was incredibly simple (and well known to many users).
Never the less, the author never stated a purpose for his inquiry, and I made no assumptions. Perhaps I read into the question that he wanted to see CURRENT PASSWORD complexity, length, and other characteristics... if so, my bad.
FWIW: The idea of keeping passwords in such a way as even admins cannot see the passwords is a GOOD one -- if you don't believe me, ask the admins over at DropBox -- where they just lost some 68+ million passwords to a hack... but they're all hashed! And compare their level of worry with those of Linked-IN -- who is trying to manage the loss of 100+ million actual passwords (stored in clear text!).
Dan
IT4SOHO
ASKER
It was hard to figure out how to distribute points. I appreciate everyone's assistance. Thanks!