Re: [gentoo-hardened] New Server, considering hardened, need pointers to tfm...

[Javier Juan Martínez Cabezón]

¿What can't you understand that you CAN translate one exploit in C in perl?

Are you joking? any user can write in their home directories their own
perl exploits. You can't restrict that. You can only restrict them
under rbac which scripts can be interpreted even for root, removing
execution to perl binary doesn't solve anything, because root can
still using it.

I think that you don't understand the term rbac, rbac removes root.
ROOT doesn't exists anymore.
Before talking what rbac does or not first read a bit what is it
because you don't understand it. Here you has info:

csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

Comparing DAC with RBAC is simply stupid.

Daemons chrooted can still uploading untrusted code and get it
executed with posibility of privilege scalation even on root jail.

Telling me that you dont find sense of rbac in servers you told me
everything, this gives fine grained access controls, less privileges
approach without getting one full privilege approach for one part of
daemon (those permited to SUID to inner user in the daemon and to bind
to port < 1024 so before dropping)
With rbac a bug in the privilege code of a daemon doesn't grant access
to for example /etc/shadow it's confined, this does not happen
necessary under servers even under chroot.

 The openbsd kernel maybe more secure but read it is as horrible as to
read one economist reference book. I have never seen so many if UID
!=0 in so many different places in so many different functions as in
its kernel, maybe it's one of the lonely systems that read the source
code in assembler is easier even than read it in source C code.
Granularity is a word that openbsd developers seems to have forgotten
in their vocabulary and the word "comment the code" too.

Have you read it? or you have this idea about the goodeness about
their code because you read it in some web page?

Systrace is so dead that his hair is kilometers of long, when did they
do the last modification of their source code? in the 18th century?,
you confuse even too rbac with systrace, systrace is not an rbac it
just controls only which syscalls can a binary make, no granularity at
all.

Please repite with me: C exploits could be translated into perl. Any
user can write their own exploit in their home directory and with only
this sillyness execute it: scriptkiddie@hell:~$/bin/perl
./mysuidpreferedexploit.

 No need to execute privileges just only read one, users can know
howto write perl code. Users can use functions in perl or in python,
so users can do everything they want without getting execute priv and
only with a write permission to some directory (/tmp and
/home/hisdir). This can only be controlled with an RBAC approach
nothing more.

And not is not a bug perl, is using perl to write exploits they are
different questions.

2011/12/12 Kevin Chadwick <ma1l1ists@××××××××.uk>:
> On Mon, 12 Dec 2011 18:38:28 +0100
> Javier Juan Martínez Cabezón wrote:
>
>> Now please tell me how under this circunstances could root to make nothing.
>
> What are you asking?
>
> The heart of the OS is the kernel. The OpenBSD kernel is more secure
> and always will be full stop because that is their main aim. Think about
> the exploits in the Linux kernel for all those years whilst they were
> present someone could have been exploiting them and still untill the
> next one is added and/or found, one of them can likely bypass RBAC.
> Restrictions upon root on OpenBSD have been shown to be bypassable
> locally on Pentium >2s via cpu management mode by a root user, it's
> still difficult. Therefore I try to use certain hardware and will still
> use chflags sappnd etc..
>
> Your example about execution can be controlled via file permissions, if
> someone allows arbitrary running as root, RBAC or not that is dumb.
> Your daemons should be chrooted as normal users so for servers rbac
> means very little to me but I would use it if I ran Linux servers and
> am planning to use it on my Linux desktops and OpenBSD would likely code
> it if they had many more developers and got lots of the other stuff they
> want done and couldn't find any more bugs. They certainly wouldn't
> refuse a working and well written patch. For desktops or more
> exploitable systems rbac gains some weight, so does systrace but all
> these tools are good things (don't mention the races in systrace
> because I'm not interested and it's still useful) and RAWIO is off by
> default on OpenBSD.
>
> Perl can only execute binaries on the system that are there and some
> will on a large install contain local exploits or bugs which can be
> reduced and fixed but not those introduced by users which could be far
> more easily exploited and you can't even hope to prevent that. If you
> can exploit the system through perl then that is a perl bug. If perl
> scripts are a problem chmod it 750 and/or systrace it or rbac it. Next
> you'll be telling me about physical security and bios batteries, well
> physical security can exist and lets stop now as it is all irrelevent
> and I'm sure everyone here is bored to death of the OpenBSD vs RBAC or
> PAX topic.
>
> All of this comes down to more is better and noexec mounts are one of
> those blanket tools possibly with effective grsec logging. Exec logging
> is usually too much to handle.
>
> Also many exploits only do one particular thing, so dismissal like this
> is simply wrong and part of the problem. In fact I remember Linux being
> criticised for execution on downloads, the best answer was noexec should
> be used. There is also the possibility of users loading up limewire
> etc..
>