Re: problem with capabilities inheritance and auditing in python

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2009-02-10 at 14:20 -0600, Xavier Toth wrote:
> On Tue, Feb 10, 2009 at 12:34 PM, Serge E. Hallyn <serue@xxxxxxxxxx> wrote:
> > Quoting Xavier Toth (txtoth@xxxxxxxxx):
> >> I was not putting capabilities on the script but rather on a compiled
> >> wrapper which execs a python script in which I need to do auditing.
> >> Will this not work?
> >
> > No, because of the way capabilities are re-calculated on exec().
> >
> >        pI' = pI
> >        pP' = (X&fP) | (pI & fI)
> >        pE' = fE ? pP' : 0
> >
> > So since the interpreter has fI=fP=fE=0 and is not setuid root (which
> > would fill in fP and/or fE to emulate privileged root), pP' and pE' will
> > be empty after exec().
> >
> > Now you could use a wrapper as follows:  Have the wrapper fill pI,
> > and then fill fI on the python interpreter.  Any user who has an
> > empty pI (which generally is all users) will execute python scripts
> > with no privilege, but when the wrapper execs the script, pP' will
> > be filled with (pI&fI) = full.
> >
> > -serge
> >
> 
> Thanks for the clarification.
> For anyone one that is interested I've included some test code. The
> wrapper is a modified version of a wrapper Stephen sent me a link to.
> Basic steps to test are:
> 1) edit the wrapper to set the path to the audit_test.py script
> 2) compiler the wrapper
>     gcc -o audit-wrapper audit-wrapper.c -lcap
> 3) set the capabilities on the wrapper and python
>     setcap cap_audit_write,cap_setfcap=epi audit-wrapper

Why cap_setfcap (set file capability)?
And do you need to set fI on the wrapper at all, given that it isn't
inheriting anything from its caller?

>     setcap cap_audit_write=ei /usr/bin/python

Is setting fE required on the interpreter?

> 4) run audit-wrapper
> 5) check audit log for audit records.
> 
> I also ran audit_test.py without the wrapper to verify that no audit
> would occur.

So this approach suffices for your need?

The alternative would be to use the setuid-root wrapper approach, using
SELinux to limit the capabilities that can be used by the domain in
which the wrapper and the script run (no need to touch the interpreter
in that case).  Did you ever track down what files the script was trying
to access that caused a problem with DAC denials?

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux