Amon Ott <ao <at> rsbac.org>
2012-04-02 06:41:46 GMT
On Thursday 29 March 2012 wrote Lorenzo Marcantonio:
> On Thu, Mar 29, 2012 at 06:28:00AM +0200, Jens Kasten wrote:
> > Mar 29 05:20:54 jaschtschik-pc kernel: 0000001371|rsbac_adf_request():
> > request CHANGE_OWNER, pid 3859, ppid 3858, prog_name strace,
> > prog_file /usr/bin/strace, uid 1000, target_type PROCESS, tid
> > 3859(strace,parent=3858(strace)), attr owner, value 1000, result
> > NOT_GRANTED by AUTH
> > I got a result from strace.
> > It should be terminated.
> Why? it tried to setuid itself to the old owner and it wasn't listed
> in its AUTH capabilies..
> If you want to suppress these 'spurious' AUTH failures there is a build
> option: in the AUTH policy support check the 'Always allow setting to
> the same id'
> I agree that it may seems stupid but I suspect there is a formal reason
> for this behaviour
Explanation: Many programs make a setuid(getuid()) to make sure they are
really running with the correct uid and rights without a way back to root
etc. Also, most suid root programs make a setuid(0), because the suid bit
only sets euid and they want root rights for all uid types.
In RSBAC, a process may have different rights than the user normally has, e.g.
a different current RC role. setuid() would usually change the rights (RC
role etc.) to the user's default, which might be wrong in the current