Re: secoff has role 2 when log in by ssh

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 <[email protected]>:
> 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
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac
>