grsecurity forums

Hey,

Im new in RBAC policy. I use to gentoo-hardened. I used to FreeBSD and Mandatory Access Control like bsdextened (ugidfw) and i was wondering if can i achieve the same results what in MAC (FreeBSD). Mainly i want to disable possibilty watching, executing, moving to other files/folders/etc... then their own. Only access to /home/%u. Is that possible ?

Greetz,
Michał,

No, not really. There are no variables (templates) in grsec policy.

If your number of users is small enough you could do it manually:

Code: Select all

role user1 u
  subject /
     /home
     /home/user1 rwcdl

role user2 u
  subject /
     /home
     /home/user2 rwcdl

role user3 u
  subject /
     /home
     /home/user3 rwcdl



but that quickly gets out of hand, even if you use includes to avoid much copy/paste.

So the answer is no - not really. However, ordinary DAC should be enough to cover that simple case:

Code: Select all

chmod 700 /home/*


ta-da! you've made sure each user is confined to his own home and can not do anything with other users homes.
Even if you need user web pages to work, DAC is good enough.
Assuming web server runs as group www-data (and using suexec or alike for scripts):

Code: Select all

chmod 710 /home/*
chgrp www-data /home/*/public_html
chmod 2750 /home/*/public_html


users still cannot access anything in other users homedirs, but web server (and anybody else in group www-data) can still access public_html subdirs and everything in them.

if you have some specific, more complex problem to handle, describe it and people can try to show you best DAC/MAC combination to achive it.

No, not really. There are no variables (templates) in grsec policy.

I wondered myself whether dynamic parameter expansion like %u for username and so on would be a nice and useful feature.

But anyway, you can always use M4 or something like that to auto-generate policies from templates.

countermode wrote:I wondered myself whether dynamic parameter expansion like %u for username and so on would be a nice and useful feature.

They would be, but I can see a whole lot of problems trying to implement it. Now, using something %uid would be pretty easy to implement (but require sysadmins to change system structure to be useful -- for example put homedirs in /home/%UID), but %username is much more problematic. Kernel does not know about usernames, it only handles UIDs, so every time file is accessed you would have to parse /etc/passwd to find the username (which would be not only horribly inefficient, but also problematic from kernelspace/userspace separation point). More efficient alternative would be to track /etc/passwd in realtime, and reload cache of it every time it changes. But that would only solve (partly) the performance problem. Requiring user to reload policy manually every time they change /etc/passwd would work OK, but would annoy sysadmins greatly (and as you point below, can be implemented today if you wish with your faveourite text preprocessor)

Also, there is a problem that there could well be several different usernames with same UID - although not usual, it is allowed, and kernel would be unable to map UID to username uniquely (which spawns whole another set of problems - would you use only first one? last one? or all of them, creating several sub-rules? )

But anyway, you can always use M4 or something like that to auto-generate policies from templates.

Sure. There is also include directive in grsec itself which might help to keep it less cubersome for static parts of policy. But on systems with bigger number of users (where is grsec RBAC policy probably most needed) the policy would grow to quite some size, take an age to (re-)load, and eat many resources.

On the other side, grsec implementing %uid would only have one copy of policy regardless of the number of users on the system, thus being quite efficient. But sysadmins would have to change from /home/%username to /home/%uid format (perhaps keeping /home/%username -> /home/%uid symlink for compatibility). And it would not cover all cases (like allowing access to /tmp/gpg-%username etc. - but perhaps DAC is good enough for those peripheral cases; or one could set TMPDIR to /home/%uid/tmp or such and the use RBAC MAC rules to rule them along with other stuff belonging to that %uid)

Hey,

thanks for your replay. I would like to try with RBAC.

I still want to implement such a solution like freebsd. I'll show you an example that is used on my servers. Always keep people in one group called "users" and give the group gid "1000".

ugidfw add subject gid gid 1000 object 1000 filesys / jails / Oxymoron! uid_of_subject type and mode n

This rule shows that users who belong to the group "users" (ie, everyone) do not have the right to exercise 'a' and n mode or anything.

Next
ugidfw add subject gid gid 0 1000 object filesys / jails / Oxymoron type d mode x

Here, the only access to users with the "users" folder is the ability to perform and that means they do not have possibilities of reading, writing, etc. In the freebsd MAC whitelist rule.

The last example is equivalent to TPE grsecurity:
System users are in the range of 0 to 999 in this connection:
ugidfw add subject not uid root gid 666 object! gid 0:999 filesys / jails / Oxymoron type r mode ARSW

I created a second group of 666 and gid named exec. Users who are not root and do not belong to the group of 666 and they try to get to the programs, whose owner is not the interval from 0 to 999 gets permission ARWS without x or execute. Every run your program causes premission denied.

Probably terribly complicated; but I wanted to show, with the help of ugidfw TrustedBSD can write whatever comes to mind. I'd feed of the solution found in August just in this project!

[quote="mnalis"]No, not really. There are no variables (templates) in grsec policy.

If your number of users is small enough you could do it manually:

Code: Select all

role user1 u
  subject /
     /home
     /home/user1 rwcdl

role user2 u
  subject /
     /home
     /home/user2 rwcdl

role user3 u
  subject /
     /home
     /home/user3 rwcdl



Can i do it with group not user ? Then i put all users to group and set premissions.

no, you can't do the same with group, due to grsec not having %u. You can do:

Code: Select all

role somegroup g
  subject /
     /home
     /home/user1 rwcdl
     /home/user2 rwcdl
     /home/user3 rwcdl


but that is not equivalent to previous example (user1 could read/write to /home/user2 if there aren't DAC limits)

Hey,

Thanks for hint. Works well. I have a another question. How can i disable view /etc/group /etc/passwd etc... by users ? When i set chmod o-r /etc/group i getting errors. Is there any way something like flag "h" in rbac to use it for disable watching files by users ? Will any problems ?