[rsbac] unable to run most aps, rsbac 1.2.1

Josh Beagley rsbac@rsbac.org
Fri Oct 4 20:01:03 2002


Thankyou for your help, working fine now.

I am interested in your kernel, could you provide a link where I woul=
d be
able to retrieve it?


>=A0Rsbac has been changed in some areas from 1.1.2. Use
>=A0rsbac-admin-v1.2.1/src/scripts/backup_all_1.1.2 to backup Your
>=A0settings in 1.1.2 and then to recover in 1.2.1, as described on
>=A0the web site too. But, the script is not perfect, my transition:
>=A01. backup everything, to be able to recover in 1.1.2 at least.
>=A02. use backup_all_1.1.2 to backup stuff
>=A03. reboot new kernel with emergency mode
>=A04. run the script created by backup_all_1.1.2
>=A05. check the most important settings.
>=A0Look for:
>=A0ACL->Process->Default process-> check acl-s for the default
>=A0groups. Do they have get_status_data?
>=A0RC-> System admin (etc.) -> Process -> General -> Do the roles
>=A0have get_status data? if not, then set
>=A0RC-> roles -> FD -> get_status_data (if you have roles that have
>=A0only execute right on a type_fd, you might want to add get_status
>=A0right Rc->roles->SCD->network and firewall. Check rights. Don't
>=A0You want to add rights to different role than system_admin to set
>=A0firewall rules (iptables)?
>=A0Rc->roles->netobj->general (This might be set by the script - or
>=A0not) check rights to be able to bind to an interface
>=A0RC->roles->netdev->general (this might be o.k. too)
>=A0check rights to be able to configure the interface
>=A0
>=A0After these steps , if system_admin is about o.k., you can take a
>=A0chance to reboot without emergency mode, and hopefully after a
>=A0successfull network login You have a chance to set the forgotten
>=A0settings (check for NOT_GRANTED in syslog...)
>=A0
>=A0b
>=A0p.s. I just patched together a kernel:
>=A0linux
>=A02.4.19+2.4.20pre8+rsbac1.2.1+grsecurity1.9.7+freeswan2.0pre2 if
>=A0anybody interested...=20
>=A0On Fri, 4 Oct 2002, Josh Beagley wrote:
>=A0
>=A0> Hello,
>=A0>
>=A0> Just installed and compiled rsbac 1.2.1 and running fine, only
>=A0additional > policy I enable was the JAIL policy, and as yet have
>=A0not made any settings > or changes to my previous rsbac
>=A0configuration. >
>=A0> However it seems I am now unable to even run ps, as I get the
>=A0following > errors for pretty much any application:
>=A0>
>=A0> Oct  3 20:39:54 Lynx kernel: rsbac_adf_request(): request
>=A0GET_STATUS_DATA, > pid 267, ppid 112, prog_name ps, uid 1000,
>=A0target_type PROCESS, tid 1, attr > , value 0, result NOT_GRANTED
>=A0by RC ACL > Oct  3 20:39:54 Lynx kernel: rsbac_adf_request():
>=A0request GET_STATUS_DATA, > pid 267, ppid 112, prog_name ps, uid
>=A01000, target_type PROCESS, tid 2, attr > , value 0, result
>=A0NOT_GRANTED by RC ACL > Oct  3 20:39:54 Lynx kernel:
>=A0rsbac_adf_request(): request GET_STATUS_DATA, > pid 267, ppid 112
>=A0, prog_name ps, uid 1000, target_type PROCESS, tid 3, attr > ,
>=A0value 0, result NOT_GRANTED by RC ACL > Oct  3 20:39:54 Lynx
>=A0kernel: rsbac_adf_request(): request GET_STATUS_DATA, > pid 267,
>=A0ppid 112, prog_name ps, uid 1000, target_type PROCESS, tid 4,
>=A0attr > , value 0, result NOT_GRANTED by RC ACL
>=A0> Oct  3 20:39:54 Lynx kernel: rsbac_adf_request(): request
>=A0GET_STATUS_DATA, > pid 267, ppid 112, prog_name ps, uid 1000,
>=A0target_type PROCESS, tid 5, attr > , value 0, result NOT_GRANTED
>=A0by RC ACL >
>=A0>
>=A0> apoligies if the mailer wraps.
>=A0> _______________________________________________
>=A0> rsbac mailing list
>=A0> rsbac@rsbac.org
>=A0> http://www.rsbac.org/mailman/listinfo/rsbac
>=A0>
>=A0>
>=A0
>=A0_______________________________________________
>=A0rsbac mailing list
>=A0rsbac@rsbac.org
>=A0http://www.rsbac.org/mailman/listinfo/rsbac