[rsbac] secoff has role 2 when log in by ssh

[Javier J. Martínez Cabezón]

I suppose that first is inherit_user and the second
inherit_user_on_chown only isn't?

The first always does the role change to the one of the user that
calls the binary (always root) the second make the role change after a
CHANGE_OWNER request, this last is the one you should mark in the
binary. Check if AUTH permit to do this CHANGE_OWNER request
(CHANGE_AUTHED_OWNER under UM)

El día 14 de diciembre de 2009 19:26, Javier J. Martínez Cabezón
<tazok.id0 en gmail.com> escribió:
> can you put me what  "4294967292" and "4294967295"  are in human
> language in roles forced?
>
> At first I have to say you that make sshd run with 999999 boot role at
> initial role is a crazy action, make a limited role for it and change
> this. Test if sshd has capacity to change to secoffs uid by module
> AUTH(check CHANGE_AUTHED_OWNER under UM or change owner without it)
>
> Another suggestion make each user to have their own ipc
>
> 2009/12/14 Orosz Tamás <pingtomi en pingtomi.hu>:
>> Hi All,
>>
>> I have a strange problem with kernel 2.6.31.6 and rsbac-1.4.3 (prepatched)
>> after I've upgraded an rsbac-1.3.8 system.
>> The problem summary is: when I log in by ssh with the user secoff, I can not
>> manage anything, because the role of secoff is 2 (system admin).
>> I've checked lot of things, here are the outputs:
>>
>> RC role settings for sshd:
>>
>> /usr/sbin/sshd rc_force_role 4294967292 (I tried 4294967295, no changes)
>> /usr/sbin/sshd rc_initial_role 999999
>>
>> RC role 999999:
>>
>> ROLE 999999 name "System Boot"
>> ROLE 999999 def_fd_create_type 4294967294
>> ROLE 999999 def_user_create_type 0
>> ROLE 999999 def_process_create_type 4294967294
>> ROLE 999999 def_process_chown_type 4294967291
>> ROLE 999999 def_process_execute_type 4294967295
>> ROLE 999999 def_ipc_create_type 0
>> ROLE 999999 def_group_create_type 0
>> ROLE 999999 def_unixsock_create_type 4294967289
>> ROLE 999999 boot_role 1
>> ROLE 999999 type_comp_fd 0 ADD_TO_KERNEL
>>
>>
>> RC role 2:
>>
>> ROLE 2 name "System Admin"
>> ROLE 2 admin_type 2
>> ROLE 2 def_fd_create_type 4294967294
>> ROLE 2 def_user_create_type 0
>> ROLE 2 def_process_create_type 4294967294
>> ROLE 2 def_process_chown_type 4294967291
>> ROLE 2 def_process_execute_type 4294967294
>> ROLE 2 def_ipc_create_type 0
>> ROLE 2 def_group_create_type 0
>> ROLE 2 def_unixsock_create_type 4294967289
>> ROLE 2 boot_role 0
>> ROLE 2 req_reauth 0
>>
>> RC Settings of fuser secoff:
>>
>> secoff rc_def_role 1
>> secoff rc_type 1
>>
>> Here is a log, when secoff log in by ssh:
>>
>> Dec 14 18:36:25 node1 kernel: [78018.570228] 0000239323|rsbac_adf_request():
>> request CHANGE_OWNER, pid 12390, ppid 11099, prog_name sshd, prog_file
>> /usr/sbin/sshd, uid 0, remote ip xxx, target_type FILE, tid Device 00:10
>> Inode 4 Path /dev/pts, attr none, value none, result GRANTED (Softmode) by
>> FF RC ACL
>> Dec 14 18:36:25 node1 kernel: [78018.586986] 0000239324|rsbac_adf_request():
>> request CHDIR, pid 12393, ppid 12392, prog_name sshd, prog_file
>> /usr/sbin/sshd, uid 400, remote ip xxx, target_type DIR, tid Device 08:01
>> Inode 208960 Path /home/secoff, attr none, value none, result GRANTED
>> (Softmode) by FF RC ACL
>> Dec 14 18:36:25 node1 kernel: [78018.587274] 0000239325|rsbac_adf_request():
>> request EXECUTE, pid 12393, ppid 12392, prog_name sshd, prog_file
>> /usr/sbin/sshd, uid 400, remote ip xxx, target_type FILE, tid Device 08:01
>> Inode 57937 Path /bin/bash, attr none, value none, result GRANTED (Softmode)
>> by DAZ FF RC ACL
>>
>> But, secoff has still role 2 event his uid is 400, and rsbac rejects any
>> modification, for eg:
>>
>> Dec 14 18:37:48 node1 kernel: [78101.974042] 0000239326|check_comp_rc_scd():
>> pid 12444 (attr_get_file_d), owner 400, rc_role 2, scd_type 32, request
>> READ_ATTRIBUTE -> NOT_GRANTED
>>
>> With rsbac 1.3.8 it has been working well before . I compared the
>> configuration with another working rsbac 1.3.8 system, it's the same.
>>
>> When I log in by console (or by telnet, only for tesing), everything is
>> fine.
>>
>> Any idea, what was my mistake?
>>
>> Thanks!
>> Tamas
>>
>>
>>
>>
>>
>> _______________________________________________
>> rsbac mailing list
>> rsbac en rsbac.org
>> http://www.rsbac.org/mailman/listinfo/rsbac
>>
>