grsecurity forums

Hi, I need some help with this :p

I got a server with Apache running under it own user (apache, uid 1001) and it own group. I want that this user is able to open files that aren't in owner by his group or himself that are masked as 700.

So, for example, /var/www/site.com is ownet by user site.com and group site.com, and Apache need to open the file /var/www/site.com/index.html that its also owner by site.com

I try this ACL:

-CAP_ALL
+CAP_DAC_OVERRIDE
+CAP_DAC_READ_SEARCH

It doesn't work, I'm doing something wrong?

One more thing, sorry for my english, I'm working on it.

CAP_DAC_OVERRIDE allows root to access files that normal DAC permissions would not allow him to access (eg: some file owned by another user/group that did not have world-* permissions) This has no effect for non-root processes. There is currently no way in the system to restrict access in that way. I may add it as a feature to 2.0, however.

-Brad

On a second reading, it looks like you want to grant additional privilege to a non-root process. This will never be possible within grsecurity.

-Brad

what we want to do (i work with qwerty) is remove CAP_DAC_OVERRIDE AND CAP_DAC_READ_SEARCH from root and grant only CAP_DAC_READ_SEARCH to apache.

this way, in a shared hosting environment we could have something like:

drwx------ wwwser1.wwwuser1 /wwwuser1
drwx------ wwwser2.wwwuser2 /wwwuser2

un such a way that individual users would not be able to read other users contents.
But we do need user apache to be able to read (not execute, as this goes though suexec being setuid and setgid wwwuserx)

I've seen +CAP_DAC_READ_SEARCH or +CAP_DAC_OVERRIDE (i dont recall which one right now) on the debian secure acls for apache tha come with grsec. What does it mean, as it is not granting the capability?

Help anyone ?
Thanks.

Joel.

It's in the ACLs for 1.9.x that way because it applies both to the apache process when it's running as root, and when it runs as non-root. We don't raise capabilities, we only drop them. So having +CAP_something simply means this is one capability that we don't drop. If the process doesn't have the capability raised (in this case, the non-root apache process doesn't) then the +CAP_whatever means nothing. You could do what you wanted with a modification to apache, however.

-Brad

Brad, thanks for the reply.

I do not know what do you mean by 'modification to apache'.
We do not wanto to run apache as root, anyway root has less privileges than user apache by this point. We ACL'ed everything away from him.

What I thought we could do (and I assume you won't like it) is change this:
if (cap_raised(current->cap_effective, cap) && gr_is_capable(cap))

to this:

if (gr_is_capable(cap))

in include/linux/sched.h

and this:

if (!gr_acl_is_enabled())
return 1;

into this:

if (!gr_acl_is_enabled())
return cap_raised(current->cap_effective, cap));

in grsecurity/gracl_cap.c

So that capabilities would work as usual when grsec is disabled, but they are overriden completely by the acl configuration when grsec is enabled.

That way I can do +CAP_DAC_READ_SEARCH on apache user role and it would be able to access.

For safety all the ACLs i have now start with -CAP_ALL followed by the ACLs I want it to have.


Nevertheless this is my first attempt at kernel hacking and probably there are things missing.

If you could comment on the above I would greatly appretiate it.

Thanks,
Joel A. Chornik

That should be ok, as long as you don't raise those capabilities on anything but stuff running as daemons. It could get very ugly if you them on on some binary that can be run as a regular user.

-Brad