[rsbac] Strange random errors

Rafal Bisingier ravbc at man.poznan.pl
Fri Jun 24 12:43:05 CEST 2005


On Fri, Jun 24, 2005 at 12:23:38PM +0200, Amon Ott wrote:
> On Freitag 24 Juni 2005 11:53, Rafal Bisingier wrote:
> > On Fri, Jun 24, 2005 at 10:57:36AM +0200, Amon Ott wrote:
> > > On Freitag 24 Juni 2005 10:32, Rafal Bisingier wrote:
> > > > I'm using
> > > > 
> > > 
> http://fixed.rsbac.mprivacy-update.de/linux-2.6.11-rsbac-v1.2.4-pax-20050613.tar.bz2
> > > > compiled without symlink redirection, but quite offten I obseve
> > > > problems running different programs. There are two type of 
> errors. 
> > > First
> > > > ends with plain "memory fault", or "segmetation fault" and a 
> program
> > > 
> > > Do you use RSBAC User Management?
> > 
> > Yes.
> 
> It might be related to that. Does "id -G <username>" work?

No. Memory fault.

> > > > crash, the second is: "Inconsistency detected by ld.so: rtld.c: 
> > > 1075: dl_main:
> > > > Assertion `_rtld_local._dl_rtld_map.l_libname' failed!"
> > > 
> > > Never seen this message before. Does this also happen with PaX 
> > > disabled?
> > 
> > I had to check it, but it never happens with Maintenance kernel.
> 
> Only trying to weed out other reasons. Hmm, no idea now.
>  
> > > > BTW: I tried to use FF module. I wanted to set execute_only flag
> > > > on some files, but then on every exec I got an error for READ
> > > > request not granted by FF (behaviour of FF module is corect, but 
> why 
> > > I
> > > > need read right to just run a progam?)
> > > 
> > > All scripts first start the interpreter, which then READs the 
> script 
> > > to interpret it. execute_only only works for binaries. Please try 
> the 
> > > file utility, then you will see how many programs are scripts.
> > 
> > This was a binary file.
> 
> Hmm. It should not need to READ itself. Or does it READ something else 
> in the dir?

No, it always try to READ the binary file. Eg (with FF execute_only):
Fri Jun 24 11:34:35 2005 :<6>0000005733|rsbac_adf_request(): request
READ, pid 14524, ppid 1460, prog_name rsbac_jail, prog_file
/usr/local/bin/rsbac_jail, uid 0, audit_uid 0, target_type FILE, tid
Device 08:05 Inode 2268378 Path /usr/local/clockspeed/bin/clockspeed,
attr none, value none, result NOT_GRANTED by FF

file /usr/local/clockspeed/bin/clockspeed returns:
/usr/local/clockspeed/bin/clockspeed: ELF 32-bit LSB executable, Intel
80386, version 1 (SYSV), for GNU/Linux 2.4.6, dynamically linked (uses
shared libs), stripped

> > > > One more thing with the FF module (make it a feature request):
> > > > I'd like to have FF++ module with rights changed to 2-bits with 
> the
> > > > meaning:
> > > > 0 - no access of this type
> > > > 1 - only this type access
> > > > 2 - inherit this type right
> > > > 3 - grant access of this type
> > > > I think this would make FF module much more usefull. ;-)
> > > > I would do this myself, but my programing skills are too low :-(
> > > > I know there is enough work with 1.2.5 currently, but maybe in 
> 1.2.6
> > > > this could be done... ;-)
> > > 
> > > Mind making a list of what accesses you would like to see 
> controlled 
> > > in this way? Default would be 2 for most rights, root dir default 
> 3.
> > 
> > Do you mean what flags should be 2bit? READ, WRITE, EXECUTE, SEARCH,
> > APPEND, and maybe MOUNT, CREATE and DELETE and metaright FOPEN
> > (applicable for dirs only, meaning that files in it can/not be 
> opened)
> > For all this flags default would be exactly as you said.
> 
> This was the list, yes.

:-)

> > BTW: If I change (eg. replace) some file with extra rights set (so 
> the
> > new file gets default rights) are the RSBAC entries for the romeved 
> inode
> > also removed? I mean: there is no possibility, that creating a file 
> on
> > inode which in the past had some extra rights applied will grant 
> those
> > rights to this new file also? I don't think this can be true, but 
> just
> > want to check it (I didn't found anything about it in the docs).
> 
> If you remove an inode, all associated attributes get removed, too. If 
> you only overwrite a file, it is each module's responsibility to act 
> accordingly.

That's what I wanted to hear. ;-)

> > BTW2: Who to write to if I'd have some docs updates (even realy 
> > small ones)?
> 
> Please ask kang at rsbac.org for a Wiki account and change the docs 
> yourself.

ok

-- 
Rafal Bisingier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rsbac.dyndns.org/pipermail/rsbac/attachments/20050624/92803007/attachment.bin


More information about the rsbac mailing list