From: Keith Matthews <keith_m@sweeney.demon.co.uk>
Subject: Re[6]: RSBAC v1.1.1 problem
Date: Tue, 3 Apr 2001 19:32:35 +0100 (BST)
Next Article (by Date): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Previous Article (by Date): Re: Rule Set Based Access Control (RSBAC) Amon Ott
Next in Thread: Re[6]: RSBAC v1.1.1 problem Keith Matthews
Articles sorted by: [Date]
[Author]
[Subject]
On Tue, 3 Apr 2001 14:09:29 +0200 Amon Ott <Amon Ott <ao@rsbac.org>> wrote: > Well, they are called the 'dialog menu tools'. In my tool tree, the menue= s > already check for dialog and give a clear message, if dialog is missing. = You > will see this in 1.1.2. > =20 What I was trying to say is that I could not find anything that clearly indicated that dialog did not come with the rest of RSBAC and has to be acquired separately. > > Having got that bit to run I still cannot deal with things. Strange > > message are in the logs, for example it is claiming to initialise itsel= f > > as v 1.1.0, (I have rechecked that it was the 1.1.1 tarball) and most o= f > > the modules are reporting that they cannot find files (e.e. Dev ACI cou= ld > > not be read). >=20 > This is really weird. I never had that. Did you possibly extract the 1.1.= 1 > tarball over an existing RSBAC 1.1.0 kernel without a make dep afterwards= ? Thought of that one before posting last night, untarred again, make dep, make bzImage, make modules, make modules_install, make install. No change >=20 > The reports are OK - ENOTFOUND just means that you never changed anything= in > this list, so it never got written. This at least should be in instadm.ht= m, > section 'First Boot'. Fine for first boot, perhaps it could be made a little clearer that this will happen on subsequent boots if nothing is changed. The log messages 'generating standard entries' sort of imply that something will be changed from the initial first load state. > =20 > > I also noticed that the secoff cannot get to objects to change access > > unless they are below his own home directory, perhaps this is a > > consequence of the initialisation problems. >=20 > In default settings, secoff gets full permission to everything, except cl= ear > sysadmin jobs, e.g. mounting etc. >=20 > Which module(s) deny the desired access? None, I do get a list of 'RSBAC -EINVALID_REQUEST' lines, without further data as far as I have been able to check (my reaction time with scroll lock is not too good). there must be about 20 each time I try to select a new item on the menu. >=20 > Also, you could try to reboot a non-RSBAC kernel, rm -r /rsbac and reboot= RSBAC > with rsbac_auth_enable_login. This must restore the default settings.=20 Will try. >If it > still fails, I would have to get my hands on your PC. >=20 A trifle difficult ! -- Keith Matthews Frequentous Consultants - Linux Services,=20 =09=09Oracle development & database administration - To unsubscribe from the rsbac list, send a mail to majordomo@rsbac.org with unsubscribe rsbac as single line in the body.
Next Article (by Date): Re: Rule Set Based Access Control (RSBAC) Stephen Smalley
Previous Article (by Date): Re: Rule Set Based Access Control (RSBAC) Amon Ott
Next in Thread: Re[6]: RSBAC v1.1.1 problem Keith Matthews
Articles sorted by: [Date]
[Author]
[Subject]