Override standard access

[xrath]

Out of interest - is it possible to override the standard linux access of user:group and ugo permissions using grsecurity/RBAC?

[onyx]

No, it's not possible I believe.

[hmhansolo]

you may want to look into extended acl attributes.. that way u can get a more granular control... the only problem with this, is that if you transfer i file from a extended attribute enabled filesystem to one that is not, i believe you lose all the attached attributes...

[Partyzant]

I think it would be one of the most useful features. I mean something like:

Code: Select all

subject /usr/bin/passwd dp {
   /etc/shadow rw!
}

! would be "override DAC for this entry, use only GRSEC permissions".

Now, with such simple rules I could get rid of most suid-bits in my system. Without ! I must leave suid-bits on or use something like that:

Code: Select all

subject /usr/bin/passwd dpo {
   /etc/shadow rw
   /
   +CAP_DAC_OVERRIDE
}

But that might be easier to misconfigure if something more sophisticated is needed. Take that real-life example: a group of users has a directory (let's call it /common) where they want to be able to edit and delete every file in every subdirectory.

With ! I could just write:

Code: Select all

role those_users G
subject / {
  /common rwx!
}

Without ! I cannot do anything like that. Giving them CAP_DAC_OVERRIDE is not an option and what I do now (a cron job running chgrp and then chmod g+rw) is, let us say, quite dirty a solution.

RSBAC has an ability to disable DAC checking for given objects (inheritable), but it has another problem - if I disable DAC for /common, I have to setup permissions for every possible subject that would want to access anything under /common - a nightmare to maintain.

[j0hn]

Hi, I really like this idea, especially Partyzant's way.

For example: I could put my webserver (including configs, userfiles ...) to a special place like /var/www and create a role that permits to do unrestricted file operations (like root) to this place.

Code: Select all

role webadmin sAG {
 subject / {
  ...
  /var/www !rwx
 }
}


I know grsecurity doesn't raise permissions, but in this case it really makes sence.


2.
It should be possible to define the uid, euid for subjects started under a role.

This way I could create roles for root-only commands (mount/umount, iptables, apt-get,... which require uid 0) that can be assigned to any user.
The system can be completely role-based, so there is no need for one root anymore. You just assign the specific roles to the responsible users.

Code: Select all

role mounter sAG {
 ...
 subject /sbin/mount uid:0,euid:0
}

If somebody with role "mounter" executes "/sbin/mount", this will be run under uid 0 and euid 0.

Maybe then it would also be usefull to be able to raise/overide capabilities with: !+CAP_ALL
For mounting no further capabilities are neccessary, but there are other commands that could need them.


Please tell me your opinions
and whether these two features will be included to grsecurity.

Thanks in advance.
John

[Loggy]

I don't see the need for this to be part of grsec. There are POSIX ACLs that will do this and these work well, particularly with the better filesystems like XFS. They are broken on ReiserFS and they can put a small overhead on access (although the way the filesystem is set up can alleviate this for XFS). Of course they need to be enabled in the kernel and the tools installed.

DACs can offer adequate protection for normal use, particularly if sysadmins don't install everything with world access (as do most distros ). grsec offers security tightening and this is especially important for systems files as well of course of protecting the system from abuses like chroot. POSIX ACLs enable you to allow a specific user or group access to a specific file or directory - ie relaxing security. They can be set by the user if setfacl and getfacl have world-execute permissions and there are no system security implications of this. Of course you can also allow specific user access to system files if you want ...

If you have DACs set, a POSIX ACL on a file will override it but if access is also controlled by grsec, the grsec controls will dominate.