Inheritance of object ACL

[salam]

Hi,

I read about flow of matches in wiki to understand how the inheritance works. I have following configuration in test user role:

Code: Select all

role testuser u
role_allow_ip 0.0.0.0/0
subject / {
        /
        /home                           r
        /home/testuser                  r
        /home/testuser/.viminfo         rwcda
        /home/testuser/.viminfo.tmp     rwcda
        /lib64                          rx
        /tmp                            rwcda
        /usr                            r
        /usr/bin                        rx
        /usr/lib64                      rx
        /var                            r
        -CAP_ALL
bind disabled
connect 0.0.0.0/0:0-65535 stream tcp
connect 0.0.0.0/0:0-65535 dgram udp
sock_allow_family all
}

subject /usr/bin/vim {
bind disabled
connect disabled
}


When i do just "vim" and immediately quit it, i receive permission denied:
(testuser:U:/usr/bin/vim) denied create of /home/testuser/.viminfo for writing by /usr/bin/vim

From what I read, if there is no such object in /usr/bin/vim subject, next most specific object permissions should be applied. As there is no 'o' flag for vim subject, it should inherit all object permissions from /usr/bin, then /usr subject (do not exist in the user policy) and last, from / subject

According to /, ".viminfo" file has rwcda permissions, so when inherited from /, vim should be able to create and write to this file.
When I delete .viminfo object from / subject and add it to vim subject, all works ok. Same as when i delete vim subject completely (so / subject will apply). So it looks like the subject did not inherit the permissions. Why did this happen?

[spender]

What's the grsecurity patch filename used and the gradm tarball version? I'm unable to reproduce this, and it should indeed work as you describe.

Thanks,
-Brad

[salam]

Hello,

I'm using hardened gentoo sources 3.11.7-r1 and gradm version 2.9.1.
What i also noticed is that any subject that does not have its own ACL within user role (for example simple "/bin/touch") gets correct rwcda permissions to the specified file. When i create its own subject (without any objects and without 'o' flag to keep inheritance), I don't have create access to the object anymore until I specify the object directly within this own subject.

Also, when I create the file with any other process (/bin/touch, /bin/cat, even /bin/nano), subject /usr/bin/vim is able to delete it, but not create it again. So it looks like rwda permissions are inherited correctly, but create permission not.

Thanks

[spender]

Can you reproduce it with our latest kernel and gradm? I can only look into it further then (as I can't reproduce it).

Thanks,
-Brad

[salam]

I updated to 3.13.6-r3 hardened gentoo and did some cleanup in my ACLs. Currently, all looks OK.

Thanks