0

My question is similar to these:

From those, I understand that SELinux could accomplish my goal. But we do not have the resources to use SELinux, so I want to know if there is another way -- specifically Grsecurity (or AppArmor).

Background: In our small organization, we have a few developers and a junior sysadmin who all have full root access and physical access to the servers. They need to be able to do server maintenance and a variety of other tasks which require fairly unrestricted sudo rights.

However, these privileged users do not have the password to unlock the encrypted filesystem after rebooting. (When the server is running, they currently have full access to all files, of course. Hence my question.)

As in the referenced questions above, my requirement is that these root users not have access to data which is located under certain directories. Can this be accomplished with Grsecurity alone?

Linux Kernel Security (SELinux vs AppArmor vs Grsecurity) - nixCraft indicates that Grsecurity is a MAC (mandatory access control) but then specifies that:

it is a RBAC implementation using access control lists.

I'm not familiar with what that means. (We do use ACL'S.) I understand that a MAC will allow me to implement a policy limiting access to the directories in question even for users with full sudo rights. So will Grsecurity do this?

I believe the fully encrypted file system will prevent a user from rebooting with a live USB key (or similar) to bypass the running OS and access those locations.

Can we accomplish this goal with only Grsecurity (and ACL's)? That would be ideal. If not, can we accomplish the goal with AppArmor?

  • RBAC is role-based access control, so you'll assign users roles and assign permissions to those roles. Grsec should have ACL capabilities, have you checked their documentation? – user Dec 11 '19 at 20:45
  • @user Yes, as I stated Grsecurity uses ACL's and our filesystem supports ACL's. Does that mean I can accomplish my goal with only Grsecurity and ACL's? – MountainX Dec 11 '19 at 20:47
  • 1
    Grsec's ACL function does not require ACL support on your filesystem. You can prevent root and other users from accessing files with their ACL system. – user Dec 11 '19 at 20:49
2

From those, I understand that SELinux could accomplish my goal. But we do not have the resources to use SELinux, so I want to know if there is another way -- specifically Grsecurity (or AppArmor).

if you want to pay for software that results in

  • su to root, or login as root
  • cd /somewhere_I shouldn't_have_access
  • permission denied

Then you can. But you can also cause that to happen for free. But in either case anyone with root and the knowledge to do so can get around this restriction. But if this meets your goal then i guess ignorance is bliss...

with linux if you have the root password then you simply have the ability to obtain access to anything under that linux operating system... including any directories under the locally mounted file systems. And anything else like SELINUX or AppArmor or grsecurity (which are kernel modules) can simply be modified or disabled or uninstalled because it happens under the authority of root in linux.

we have a few developers and a junior sysadmin who all have full root access and physical access to the servers. They need to be able to do server maintenance and a variety of other tasks which require fairly unrestricted sudo rights

there's yer probrem. you need to nail all that down specifically. If a person is not to have access to a folder then they cannot have the root password. If a person is required to have the root pw for whatever reason then they will have the ability to gain access to anything under the control of the linux operating system if they have the knowledge to do so. Privileged user also does not mean gets the root password; it means a user has some specific privilege defined in sudoers.

consider this: https://en.wikipedia.org/wiki/Grsecurity

The grsecurity patches have never been submitted for inclusion in the mainline Linux kernel, for the following reasons: Some of the features are never going to be accepted, based on what Linus Torvalds himself thinks about their implementation details and technological foundations per se: https://lkml.org/lkml/2009/1/3/126

Quite frankly, historically the patches have been a mis-match of

  • some sane stuff

  • lots of totally insane and very annoying and invasive code.

an example of the second class is the totally idiotic "emulate NX bit - badly - with code segment limits" kind of patches. These kinds of patches only add unmaintainable crap that isn't even relevant in the long run, and thus any sane maintainer (me) should refuse to take them.

The apparent inability (and perhaps more importantly - total unwillingless) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be merged.

Much of it did get merged over the years (mostly because some people spent the time to separate things out), but no, we're not going to suddenly start merging code like that just because the project is in trouble. None of the basic issues have been solved.

Linus

  • I only became aware of this after asking my question: grsecurity.net/passing_the_baton The last time I had checked a binary Grsecurity kernel had been available for my distro. That's no longer the case. – MountainX Dec 11 '19 at 22:51
  • Is AppArmour the best choice for someone with limited resources (limited skills, limited people, limited budget, etc.)? We need a simple solution for this: 1. su to root, or login as root 2. cd /somewhere_I shouldn't_have_access 3. permission denied – MountainX Dec 13 '19 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.