At least at places I've worked, terminating the logger would cause a security incident, and the central logging service have some general heuristics that should trigger a review if a log is filled with junk. Of course with enough time and root, there's ways to avoid that. But that's also usually why those with root are limited to a small subset of users, and assuming root usually requires a reason and is time gated.
That still leaves highly visible log traces if you’re following most security standards (required in .gov) since you’d have the logs showing them disabling the forwarder. The difference here is that this was like an attacker but had backing from senior management to violate all of those rules which would normally get someone fired, if not criminally charged.
That is a very serious design flaw, but I also believe it is a flaw that is addressed by SELinux. (Perhaps someone with a knowledge of SELinux can offer some input here.) That said, I'm not sure how widespread the use of SELinux is and doubt that it would help in this case since the people in question have or can gain physical access.
Not without a reboot though, and while I haven’t done that, it should be possible to protect selinux ‘s config itself with a policy, requiring boot loader access to bypass, at which point you’re dealing with a different risk level.
I’ll agree that Linux security is quite limited and primitive if compared with, say, a mainframe, but it can be made less bad with a reasonable amount of effort.
Yes. A more competent hack would have been to use their superuser permissions to do that kind of thing.
But instead they requested that logging be disabled, thus outing themselves as acting in bad faith.
At least at places I've worked, terminating the logger would cause a security incident, and the central logging service have some general heuristics that should trigger a review if a log is filled with junk. Of course with enough time and root, there's ways to avoid that. But that's also usually why those with root are limited to a small subset of users, and assuming root usually requires a reason and is time gated.
> But that's also usually why those with root are limited to a small subset of users, and assuming root usually requires a reason and is time gated.
I mean, if we were to apply the equivalent from the article, then no they would not have had a reason nor been time gated.
That still leaves highly visible log traces if you’re following most security standards (required in .gov) since you’d have the logs showing them disabling the forwarder. The difference here is that this was like an attacker but had backing from senior management to violate all of those rules which would normally get someone fired, if not criminally charged.
That is a very serious design flaw, but I also believe it is a flaw that is addressed by SELinux. (Perhaps someone with a knowledge of SELinux can offer some input here.) That said, I'm not sure how widespread the use of SELinux is and doubt that it would help in this case since the people in question have or can gain physical access.
If your root, you can just turn off selinux
Not without a reboot though, and while I haven’t done that, it should be possible to protect selinux ‘s config itself with a policy, requiring boot loader access to bypass, at which point you’re dealing with a different risk level.
I’ll agree that Linux security is quite limited and primitive if compared with, say, a mainframe, but it can be made less bad with a reasonable amount of effort.
2 replies →
Assuming the Whistleblower is telling the truth, why would they make the request if they could cover their tracks themselves