Override standard access

Submit your RBAC policies or suggest policy improvements

Moderators: spender, PaX Team

Override standard access

Postby xrath » Wed Feb 16, 2005 1:01 pm

Out of interest - is it possible to override the standard linux access of user:group and ugo permissions using grsecurity/RBAC?
xrath
 
Posts: 12
Joined: Sun Nov 16, 2003 12:02 pm

Postby onyx » Wed Feb 16, 2005 6:27 pm

No, it's not possible I believe.
onyx
 
Posts: 36
Joined: Tue Jan 20, 2004 7:46 pm

extended acls

Postby hmhansolo » Tue Feb 22, 2005 12:05 am

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...
hmhansolo
 
Posts: 32
Joined: Mon Jan 10, 2005 9:15 pm

Postby Partyzant » Thu Apr 21, 2005 4:51 pm

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.
Partyzant
 
Posts: 1
Joined: Thu Apr 21, 2005 4:24 pm

Postby j0hn » Sat Sep 03, 2005 10:29 am

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
j0hn
 
Posts: 2
Joined: Tue Jan 18, 2005 10:16 am

Postby Loggy » Tue Sep 06, 2005 4:07 am

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 ...:D

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.
Loggy
 
Posts: 14
Joined: Tue Nov 18, 2003 5:28 am
Location: UK


Return to RBAC policy development