Per Jessen schreef op 11-04-16 12:57:
If somebody needed a backup admin, you're right. What I think somebody might need is a "storage admin" who will for instance manage when, what and how backups are made, but it would not mean he/she would have access to any of those backups. For _running_ the backups, some areas might still require root, but far from all. The backup process for a mysql database would require the user for that instance. The backup process for an apache vhost would require the user for that vhost. etc etc.
Having dedicated "admins" like that would really make the opportunity for creating security holes that gave access to full root, much harder to do. You could even imagine: this was my imagining. Okay don't laugh, or maybe do. What IF. You create a secret government :P. You immunize a certain set of essential files pertaining to security. You disallow root to change them. You create a hidden user that even root cannot see. Since no one but that user (or his cronies) can see the user, and since the files that govern this cannot be changed (except for the user) you have effectively created a super-root that no one knows about (except you). Now actually you also want to limit the rights of the super-root or nothing will have changed (you would just have a new root). But next you do is create a hidden part of the filesystem (again, only visible to the super-root) and you use this as the place where you keep your auditing logs, and perhaps your backups as well. Effectively it would be very much like having a different system that has different user accounts and where logs are sent to (and backups). It's actually not much different from that. Actually it's the exact same thing only on one system. You know, the idea of "someone compromises root on system A, but cannot clear his trails because the auditing has already been sent to system B, that he cannot access". So now you have a special backup daemon/user/process that also has access to this hidden area for storing the backups. I'm not sure how to do it, but the super-admin would by default not have all the same rights that root does have. The super-admin is the only one who can "invisiblize" parts of the system to everyone else. But he doesn't need (write) access to every other part of the system. Much like our real secret governments do. So the super-admin controls the core security files. He/she could therefore change them and open up everything else in the system as well..... hmmm.... But really do you not want this user to have the authority that root has. That's a logical impossibility if the super-admin can change the entire security system.... namely the programs and libraries that control it (and configurations). My system needs some working :p. The whole reason for this system is that if some hacker enters the machine, he might destroy the contents of the machine but never get access to the "safe" vault unless he knows how to get there. But knowing how to get there would be rather difficult because root would not be able to see it or find any traces of it, the backup user does, but root won't see any open file handles, you could even go so far as to hide statistics but then you'd at some point run into anomalies ;-). In fact the only way to get to the super-admin might be through some less-privileged user. But this thing might not be visible (and might still require a secret) while using all of the standard tools (such as su).
There is software for that sort of thing out there, just not open source (as far as I have seen). Try googling e.g. "unix admin separation privileges".
It's been practised at the enterprise level for decades, AIX, HP-UX and Solaris have probably all had this functionality for quite some time.
I think it is a real shame that Linux is so primitive, but then again, that makes it possible to design your own thing on top of it. The problem with "less-primitive" is that someone might design something you do not like, and now you are stuck with it (think systemd). The more primitive something is, the less chance someone will have taken a turtle and built a castle on top of it (just to name something silly). Primitive tools have the tendency to do only one thing and do them well. A hammer is a hammer. A motorized hammer with phase-shift ability might not do what you want ;-). Design flaws also have less impact if the system is small or still at its beginnings. The bigger the system is, the worse a design flaw will become.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org