Dealing with nested subjects

Submit your RBAC policies or suggest policy improvements

Moderators: spender, PaX Team

Dealing with nested subjects

Postby mcanswer » Mon Jun 20, 2011 4:26 am

hi,

I'm trying to use nested subject for gpg executed by mutt:

ACL:
Code: Select all
subject / o {
...
 /usr/bin         rx
 /home/mcanswer/.gnupg     h
}

subject /usr/bin/mutt {
        /home/mcanswer/.maildir         rwcd
        /usr/bin/gpg2                   rx
        -CAP_ALL
        bind    disabled
        connect disabled
        sock_allow_family all
}

subject /usr/bin/gpg2
 
subject /usr/bin/mutt:/usr/bin/gpg2 {
        /home/mcanswer/.gnupg           rwcd
    /lib                            rxi
    /usr/lib                        rxi
    /etc/ld.so.cache                r
    /proc/meminfo                   r
        -CAP_ALL
        bind    disabled
        connect disabled
        sock_allow_family unix inet
}


grsec:

Code: Select all
(mcanswer:U:/usr/bin/gpg2) denied access to hidden file /home/mcanswer/.gnupg/gpg.conf by /usr/bin/gpg2[gpg:8876] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/mutt[mutt:18358] uid/euid:1000/1000 gid/egid:1000/1000

Without "subject /usr/bin/gpg2" execution of gpg is logged as "(mcanswer:U:/)". Why nested subject mutt:gpg2 isn't applied in this case?


gradm v2.2.1
kernel 2.6.36-hardened-r9 with gentoo patchset

best regards
Kris
mcanswer
 
Posts: 3
Joined: Mon Jun 20, 2011 4:01 am

Re: Dealing with nested subjects

Postby spender » Mon Jun 20, 2011 9:52 am

Hi Kris,

I'll take a look into this. Thanks for the report.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm
Location: VA, USA

Re: Dealing with nested subjects

Postby spender » Mon Jun 20, 2011 7:04 pm

Hi Kris,

I'm not convinced yet that there's any problem with nested subjects. I've tested them again here and they're working fine.

In your case, I don't believe the nested subject triggered in either case. It only appeared to in the case where you added the "subject /usr/bin/gpg2" line, where there it was logging the denial from that created subject, not from the nested subject (which would have allowed that access).

The most likely reason for this is that mutt executed gpg2 via system() or some other similar library function that executes indirectly through the shell instead of through a direct execve(). You can verify this by setting up a new set of nested subjects like this:

Code: Select all
subject /usr/bin/mutt {
        /home/mcanswer/.maildir         rwcd
        /bin/bash                   rx
        -CAP_ALL
        bind    disabled
        connect disabled
        sock_allow_family all
}

subject /usr/bin/mutt:/bin/bash
     /usr/bin/gpg2 rx

subject /usr/bin/mutt:/bin/bash:/usr/bin/gpg2 {
        /home/mcanswer/.gnupg           rwcd
    /lib                            rxi
    /usr/lib                        rxi
    /etc/ld.so.cache                r
    /proc/meminfo                   r
        -CAP_ALL
        bind    disabled
        connect disabled
        sock_allow_family unix inet
}


Substitute the /bin/bash for whatever shell you're using.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm
Location: VA, USA

Re: Dealing with nested subjects

Postby mcanswer » Tue Jun 21, 2011 8:53 am

It indeed solved the problem
Thanks
mcanswer
 
Posts: 3
Joined: Mon Jun 20, 2011 4:01 am


Return to RBAC policy development

cron