Rule set based access control (rsbac) for linux

Jens Kasten | 29 Mar 2012 06:28

AUTH

Hi,

I did a strace on mc and this is in the logfile:

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.

Jens

headers

Lorenzo Marcantonio | 29 Mar 2012 08:28

Re: AUTH

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

--

-- 
Lorenzo Marcantonio
Logos Srl

headers

Jens Kasten | 29 Mar 2012 07:42

Re: AUTH


Am Donnerstag, den 29.03.2012, 08:28 +0200 schrieb 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..
I think if AUTH say no, than its have to be.

> 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'
This option I don't have set.

> 
> I agree that it may seems stupid but I suspect there is a formal reason
> for this behaviour
>

headers

Amon Ott | 2 Apr 2012 08:41

Re: AUTH

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 
situation.

(Continue reading)