[rsbac] Trusted Path Execution and scripts

tazok tazok.id0 at gmail.com
Sat Jul 22 11:23:54 CEST 2006

2006/7/22, Jens Kasten <jens at igraltist.dyndns.org>:
> nice thinking.
> one thing, can you show my an example script wich should harm the system?
> on other thing is. for wath reason is the server running?
> is it the a webserver with has some emailstuff there, there is no reason to
> give an user a account.
> or is it a developserver. than mayby think about include also the other
> models.
> the security it  alway restrikt the usability for an user and if  get an
> ordinary user more and more rights , the securtiy of the system shrink and
> shrink in the same way.
> one point is not clear for me and this is the trusted script.
> who say it is a trusted script and wich points must get ok that the script is
> trusted?
> _______________________________________________
> rsbac mailing list
> rsbac at rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac

Well, an example script not, but imagine the bug of the do_brk that
appears here: http://isec.pl/papers/linux_kernel_do_brk.pdf.
This bug occurs in ring 0, that is, as far as I know an attacker can
take the control entirely of the kernel and could even modify kernel
structures. As far as I know simple exploits could be written in perl
or maybe python, in bash possibly not (or would be very simple making
a program crash for example, bash is a very limited language) but I'm
not sure. Because of my limited knowledge I prefer to control it (or
trying it at least) and don't let work the imagination of possible
hostile users.

The server will host a lot of services in different virtual machines,
vsftpd, mysql, postfix, dovecot, ssh, and apache with samhain and
snort controlling all. Each virtual machine will be jailed and will
have it's own role. Probably I will use the RC, CAP and JAIL into the
virtual machine and RC, RES, JAIL, CAP and even MAC out. The reason
for MAC is to isolate a bit more the vm's putting them in other
"domain" or "ring" (that is, a MAC level) and in the higher level the
main system (where I log in). I think that if the MAC of rsbac is
based on the strict *-property (to write the level of the object must
be the same that the level of the subject) putting all them in
differents levels will assure their integrity and their
confidentiality (I don't know even if it will work but it will be
funny to try it :) ). I will not do all this now but I want at least
begin writting the RC policy which will govern the base system of all
the virtual machines and the principal system.

About the trusted scripts, one trusted script could be for example one
of the /etc/init.d scripts, that is, one script that could not be
modified by any user not me (the TPE suggest that a trusted binary is
those which resides in a directory owned by root and without writing
privilege to the group owner and others), the idea is that only the
scripts I say "trusted" (that is unmodified by a third party) could be

And this is my plan and all, thanks for your help and sorry for the
perversion use of the MAC model but I'm tired of the standard uses as
may be confidential data, secret data and things like it :).

More information about the rsbac mailing list