New Server, considering hardened, need pointers to tfm...

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
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..

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon
¿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 <[hidden email]>:

> 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..
>

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
On Mon, 12 Dec 2011 20:44:37 +0100
Javier Juan Martínez Cabezón wrote:

> ¿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 know you can. No perl binary, or chmod 750 or rbac as I had said.
All exploits are bugs and it should be harder to escalate priviledges
through perl than by introducing your own C.


> 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.
>

You are simplifying everything, security is a process. Noexec is a
useful tool. How much of what I said did you read. I understand your
points and most security has nothing to do with root. I understand root
can execute files chmodded 000 and I agree that RBAC is useful, the
point is so is noexec and systrace.


> 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:

No it doesn't it restricts root. An exploit may bypass RBAC it may
bypass mount restrictions it may bypass both it may only bypass one, in
which case they are both again useful.

And OpenBSDs systrace can restrict a lot. System calls are the
hearts heart of an OS.



Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon
> You know you can. No perl binary, or chmod 750 or rbac as I had said.
> All exploits are bugs and it should be harder to escalate priviledges
> through perl than by introducing your own C.

Clear, making use intensive under openbsd as you said. With 750 even
with 700 root can stills using it, as in extension any software run by
him. It's harder programming in python than in C? in python you can
write exploits too, no it isn't harder. Any programmer can do it.

> You are simplifying everything, security is a process. Noexec is a
> useful tool. How much of what I said did you read. I understand your
> points and most security has nothing to do with root. I understand root
> can execute files chmodded 000 and I agree that RBAC is useful, the
> point is so is noexec and systrace.

Noexec is not usefull at all I give you the reason it does not
controls scripts interpretation is a false sense of security. Is
something like get a not executable stack without pax mprotect, it
does nothing alone

My system has no root, root has all capabilities in 0, so the same
privileges as a normal user has, can't do ptrace to others process,
can't read files not our, can't load modules etc etc etc. Every
capability is removed. Check rsbac.org. With rbac even root can't
access a program he has started. Read about rbac and when you get
understood which it offers then told me what it can or what does not
offers.

Systrace is dead, the project is dead. It does not exists from long ago.
>
> No it doesn't it restricts root. An exploit may bypass RBAC it may
> bypass mount restrictions it may bypass both it may only bypass one, in
> which case they are both again useful.
>
> And OpenBSDs systrace can restrict a lot. System calls are the
> hearts heart of an OS.

I have said to you that rbac can make impossible to launch untrusted
code (even exploits) executed and interpreted as in perl myperlscript.
In one of my first mail I pointed you ways in that root can do harm
and how rbac can avoid them. Root is not important because root is
only important in DAC not in RBAC. Read the link I sen't to you before
because you stills not understood this point.

Yes an system dead long ago, and not it only do this: after this bind
you can only get a listen. It gives not flexibility, granularity at
all.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
On Mon, 12 Dec 2011 22:04:30 +0100
Javier Juan Martínez Cabezón wrote:

>
> Noexec is not usefull at all I give you the reason it does not
> controls scripts interpretation is a false sense of security. Is
> something like get a not executable stack without pax mprotect, it
> does nothing alone
>

It is an extra security measure for defense in depth.

It allows easy use and a better default widely understood and
blanket setting that almost any user can understand and switch off and
so is more likely (not very) to be applied across the board.

It gives admins extra control.

Shall we get rid of file permissions because we have RBAC. We could
but I can't see that happening and for good reason.

Who said it was lonely :)

> My system has no root, root has all capabilities in 0, so the same
> privileges as a normal user has, can't do ptrace to others process,
> can't read files not our, can't load modules etc etc etc. Every
> capability is removed. Check rsbac.org. With rbac even root can't
> access a program he has started. Read about rbac and when you get
> understood which it offers then told me what it can or what does not
> offers.
>

I do and I disagree here though we are both right really as has been
the case for most of this discussion. RBAC can restrict root and
root has the potential to make Direct attacks on the kernel via the
memory, accessible devices and perhaps even RBAC itself. Things do
require priviledges and RBAC reduces those granted and is good but if
RBAC removed root the kernel wouldn't be able to turn on and off RBAC
and the boot phase wouldn't be vulnerable. I already realised that RBACs
were path and Role based, some inode based and probably many other
flavours. I looked over that pdf but I do have far better ones that
don't belittle systrace like you do.

> Systrace is dead, the project is dead. It does not exists from long ago.

> >
> > No it doesn't it restricts root. An exploit may bypass RBAC it may
> > bypass mount restrictions it may bypass both it may only bypass one, in
> > which case they are both again useful.
> >
> > And OpenBSDs systrace can restrict a lot. System calls are the
> > hearts heart of an OS.
>
> I have said to you that rbac can make impossible to launch untrusted
> code (even exploits) executed and interpreted as in perl myperlscript.
> In one of my first mail I pointed you ways in that root can do harm
> and how rbac can avoid them. Root is not important because root is
> only important in DAC not in RBAC. Read the link I sen't to you before
> because you stills not understood this point.
>

I knew this

> Yes an system dead long ago, and not it only do this: after this bind
> you can only get a listen. It gives not flexibility, granularity at
> all.


Admittedly systrace doesn't get much attention but then it does what it
says on the tin and how about Aug 2011.

http://marc.info/?l=openbsd-tech&m=131484069706394&w=2

This pdf is a bit old (2005) but it actually says the problem with
systrace is that it is so fine grained it is hard to setup well.

"http://z.cliffe.schreuders.org/publications/Honours%20Thesis.pdf"


Lets make this constructive. Maybe you can tell me which RBAC you use
and why you chose it.

Thanks

Kc

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon
> It is an extra security measure for defense in depth.
>
> It allows easy use and a better default widely understood and
> blanket setting that almost any user can understand and switch off and
> so is more likely (not very) to be applied across the board.
>
> It gives admins extra control.
>

A inefficient and useless layer if not complemented with extra measures.

> Shall we get rid of file permissions because we have RBAC. We could
> but I can't see that happening and for good reason.

file permissions are discrectional, rbac mostly mandatory, don't try
to compare them.


> I do and I disagree here though we are both right really as has been
> the case for most of this discussion. RBAC can restrict root and
> root has the potential to make Direct attacks on the kernel via the
> memory, accessible devices and perhaps even RBAC itself. Things do
> require priviledges and RBAC reduces those granted and is good but if
> RBAC removed root the kernel wouldn't be able to turn on and off RBAC
> and the boot phase wouldn't be vulnerable. I already realised that RBACs
> were path and Role based, some inode based and probably many other
> flavours. I looked over that pdf but I do have far better ones that
> don't belittle systrace like you do.

It does not restrict root, it erase it. The concept of root doesn't
exists anymore.
Give me an example of direct attack via memory as you say, accessible
devices and anything else said you before.

Raw access is fully controlled and forbidden to root, raw access to
ttys and block devices too, controlled the mount of devices etc etc
etc

You don't know what rbac is so don't speak about it because you can't
understand it


>
> Lets make this constructive. Maybe you can tell me which RBAC you use
> and why you chose it.
>
> Thanks
>
> Kc
>
I use rsbac as framework, with modules RC, ACL, exclusive UM, RES,
JAIL, MAC, PAX, AUTH and CAP running.

Root has not capabilities, not CAP_SYS_RAWIO, no DAC_OVERRIDE, not
SYS_MODULES etc etc he can only execute binaries in /sbin and /bin,
map /lib libraries and nothing else, halt has its own role and type,
so root even can't switch down the machine for example. Master role of
sshd even has more privileges than root itself.

I use rsbac because it reachs to B1 security level, level that openbsd
will never reach, it supports even secure_delete, and has some B2
charateristics as device labels are.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

pva0xd
In reply to this post by Alex Efros-4
В Вск, 11/12/2011 в 16:53 +0200, Alex Efros пишет:

> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
> > > 1)  How can
> > > 4.2.4.1. Root Logon Through SSH Is Not Allowed
> > >     increase security, if we're already using
> > > 4.2.4.2. Public Key Authentication Only
> > >     Disabling root may have sense with password auth, but with keys it is
> > >     just useless inconvenience.
> >
> > I read somewhere that security is about making things more inconvenient for
> > malicious people than for authorized ones.
> >
> > For me, immediately logging in as root is not done. I want to limit root
> > access through the regular accounts on the system (with su(do)). I never had
> > the need to log on as root immediately myself.
>
> Understood. But I still don't see how this can increase security.

To authorize you need pair: login/password or login/priv_key. By
requiring login be guessable too you make probability to guess both
harder. Remember how debian  made possible to brute-force private
key[1]? Additional layers really may help in some situations...


1. http://digitaloffense.net/tools/debian-openssl/

--
Peter.


Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

pva0xd
In reply to this post by Alex Efros-4
В Вск, 11/12/2011 в 16:53 +0200, Alex Efros пишет:

> On Sun, Dec 11, 2011 at 02:25:19PM +0000, Sven Vermeulen wrote:
> > > 1)  How can
> > > 4.2.4.1. Root Logon Through SSH Is Not Allowed
> > >     increase security, if we're already using
> > > 4.2.4.2. Public Key Authentication Only
> > >     Disabling root may have sense with password auth, but with keys it is
> > >     just useless inconvenience.
> >
> > I read somewhere that security is about making things more inconvenient for
> > malicious people than for authorized ones.
> >
> > For me, immediately logging in as root is not done. I want to limit root
> > access through the regular accounts on the system (with su(do)). I never had
> > the need to log on as root immediately myself.
>
> Understood. But I still don't see how this can increase security.

To authorize you need pair: login/password or login/priv_key. By
requiring login be guessable too you make probability to guess both
harder. Remember how debian  made possible to brute-force private
key[1]? Additional layers really may help in some situations...


1. http://digitaloffense.net/tools/debian-openssl/

--
Peter.



Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
In reply to this post by Javier Juan Martinez Cabezon
On Tue, 13 Dec 2011 22:20:00 +0100
Javier Juan Martínez Cabezón wrote:

> Give me an example of direct attack via memory as you say, accessible
> devices and anything else said you before.

I suggest you do some more reading at grsecurity.net or even the
OpenBSD mailing list. I haven't got time to hunt down the two references
that stick in my mind but keep your ears open and you may realise one
of the kernel exploits could/can/will do just that. Do you really
believe it's impossible??!!


>> Shall we get rid of file permissions because we have RBAC. We could
>> but I can't see that happening and for good reason.

> file permissions are discrectional, rbac mostly mandatory

I have no idea what you are arguing with, you just keep trying to twist
what I say because you have a bee in your bonnet about MACs as the
answer to everything and a panacea, they aren't but they are useful as I
have said. Personally I wouldn't swap an OpenBSD kernel for the Linux
one with RBAC on my servers atleast. One day with a risky setup, I
might in that instance. I wonder why kernel.org didn't use RBACs,
especially RSBAC or even chroot. How embarrassing for such an automated
attack to get through. Is bugzilla.kernel.org still down? That wouldn't
have happened if they were using OpenBSD. It might be a good idea to use
a different kernel to the one they are hosting anyway even with many
eyes. And before you think well this is just me clutching at straws with
your tunnel vision, it relates exactly to what I was talking about
of likelihood of use.

>> don't try to compare them.

Of course you should and I was saying much of RBACs can be replaced and
you use both and it adds to defence in depth. Your notion of replacing
DACs? I see good and bad in that.


>> It does not restrict root, it erase it. The concept of root doesn't
>> exists anymore.

What is root, it is the root of the system not just a user. If it
didn't exist the kernel wouldn't be able to turn RBAC off now would it.
You have been drawn in by the wonderful marketing of imagine a system
where root doesn't exist. Would your analogy be the kernel recreates
root. If so, fine it makes no difference but is less correct.


> I use rsbac because it reachs to B1 security level, level that openbsd
> will never reach, it supports even secure_delete, and has some B2
> charateristics as device labels are.


And yet your kernel has bugs added every day without much security
consideration. What you don't understand is that RBAC is a security
layer that the root of the system has control of. What can
your /sbin/init do, what can the kernel do? Some rootkits can actually
go the other side of the kernel even, far above where RBACs are.

Yeah and Cisco's are certified for use by some enterprise manager and
yet they have proven full of root exploits. Certified encryptions are
often less secure than others.

I repeat it ALL depends on the application, even the hardware. You
could reduce the Linux kernel right down to protect the RBAC. Which
was my original point.

Of course then I wonder if the RBAC would actually ever be needed but
it's ALL GOOD.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon
> I suggest you do some more reading at grsecurity.net or even the
> OpenBSD mailing list. I haven't got time to hunt down the two references
> that stick in my mind but keep your ears open and you may realise one
> of the kernel exploits could/can/will do just that. Do you really
> believe it's impossible??!!
>
I give you proofs because  the arguments you defend are wrong, give
proofs about the oposite if you can.

I told you, with a secure TPE (so scripts fully controlled) tell me
how to write one kernel exploit under bash without calling external
code.


>>> Shall we get rid of file permissions because we have RBAC. We could
>>> but I can't see that happening and for good reason.
>
>> file permissions are discrectional, rbac mostly mandatory
>
> I have no idea what you are arguing with, you just keep trying to twist
> what I say because you have a bee in your bonnet about MACs as the
> answer to everything and a panacea, they aren't but they are useful as I
> have said. Personally I wouldn't swap an OpenBSD kernel for the Linux
> one with RBAC on my servers atleast. One day with a risky setup, I
> might in that instance. I wonder why kernel.org didn't use RBACs,
> especially RSBAC or even chroot. How embarrassing for such an automated
> attack to get through. Is bugzilla.kernel.org still down? That wouldn't
> have happened if they were using OpenBSD. It might be a good idea to use
> a different kernel to the one they are hosting anyway even with many
> eyes. And before you think well this is just me clutching at straws with
> your tunnel vision, it relates exactly to what I was talking about
> of likelihood of use.

I have never said to eliminate DAC. I just told that ONLY DAC as
openbsd do is a bad option and insecure.
You can substitute DAC with RBAC (and RSBAC gives an option to do it).

Now DAC and RBAC are layered, RBAC can be secure without DAC, DAC
WOULD NEVER be secure without RBAC.


> What is root, it is the root of the system not just a user. If it
> didn't exist the kernel wouldn't be able to turn RBAC off now would it.
> You have been drawn in by the wonderful marketing of imagine a system
> where root doesn't exist. Would your analogy be the kernel recreates
> root. If so, fine it makes no difference but is less correct.

I repeat you (and get your ears cleaned) UID 0 is only relevant UNDER
DAC approach.

RBAC doesn't use UIDS just roles read about rbac AGAIN. And UID 0
under rbac can do NOTHING. UID 0 can't switch off nothing only role
admin can do it, and usually is not UID 0, in rsbac is UID 400.

Some binaries with independency of which user executes it, change to
their own role and can do ONLY which his role can do., for example my
syslog-ng role when executed can only access in append mode to logs
files and mapping libraries under /lib, can just access to /dev/log. A
exploit ran against syslog will NOT GET full control over the system
even when ran under root account without dropping just to what his
role can do.

Root in a DAC can do which it does because the capabilities, in my
system (I told you again) root has not capabilities, is just a simple
user.

As you can suppose this user 400 doesn't launch daemons (neither init)
and run any software he just administrate the policy, and nobody can
suid to his uid without getting authenticated (password) against UM
module, so there is not way to get suid to his account in a exploit
approach.

I told you many times that TPE under proper RBAC is secure, because
only a bash script without calling extern code could be launched as an
exploit, so it's nearly impossible to do it. Write me a bash script
kernel exploit if you can.

Even with that this role admin or authority could be fixed forever
just revoking to his role these privileges.


> And yet your kernel has bugs added every day without much security
> consideration. What you don't understand is that RBAC is a security
> layer that the root of the system has control of. What can
> your /sbin/init do, what can the kernel do? Some rootkits can actually
> go the other side of the kernel even, far above where RBACs are.

Read the orange book, this is the question because mandatory access
controls exists to confinate damage and avoid them. My init can't suid
to secoff UID, and he can't only call scripts and nothing more. Getty
runs with his own role, scripts with their own, login with it's own
and init with it's own. ROOT DOES NOT CONTROL RBAC, RBAC controls him.

There is no way that a rootkit could access to kernel memory,
/dev/mem, ioports an alike devices are fully controlled and module
interfaz too and kernel sources too. Tell me how the hell can anyone
launch a ring 0 rootkit, and give proofs as I did a not simple search
in grsec or openbsd sites.


> I repeat it ALL depends on the application, even the hardware. You
> could reduce the Linux kernel right down to protect the RBAC. Which
> was my original point.
>
RBAC IS the kernel, is the PCB. The PCB protects himself from
userland, and root is part of this userland, and for this reason root
has not rights over it, it has them over him. By this reason the
access control is mandatory.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Alex Efros-4
Hi!

On Wed, Dec 14, 2011 at 04:27:45PM +0100, Javier Juan Martínez Cabezón wrote:
> I told you, with a secure TPE (so scripts fully controlled) tell me
> how to write one kernel exploit under bash without calling external
> code.

How about
    $ perl -e 'exploit code here'
or just
    $ perl
    exploit code here from stdin
    Ctrl-D
?
Is your current RBAC configuration prevent this?

As for me, I tend to agree with you about RBAC, but I think to make RBAC
really useful it rules/roles must be provided by software developers -
just like they now provide README and Makefile, because only software
authors actually know which files, devices and syscalls used by their
applications and how these requirements change from version to version.

I've tried different RBAC implementations few times, but got tired fixing
roles and rules - on usual hardened workstation after enabling RBAC (even
after auto-learning mode) everything become broken in many unexpected
ways, and it took too many time to realize each time this isn't a bug in
some software but just RBAC misconfiguration and fixing it. Probably
workstation isn't good place for RBAC. But on most of my servers there are
a lot of perl scripts, and we often add new scripts, and writing RBAC
rules for all of them looks too complicated. Another server must have php,
ftp, many wordpress sites and other php crap - and I can't even imagine
how this can be secured using RBAC.

BTW, while I agree with you about useless 'noexec' for /tmp, it's usually
cheap way to stop few scriptkiddies with default exploits, so there is no
harm in using it. And no real harm in don't using it.

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon
when perl is executed as interpretation (perl mynastyscript) it
changes his role to perl_role

perl role has only the rights to open scripts marked as trusted, if
the script is trusted, read is permitted and a change of role happens
to user role is done. If it's not trusted, then perl can only do what
perl_r do (mapping standard libraries), perl_r can map libperl.so, it
can write the code this library permits. He shall rewrite the wheel
too many times.

Maybe I could make checks forbidding this library mapping and granting
only when transition is done (so when is clear that the script is
trusted). I shall check it.


2011/12/14 Alex Efros <[hidden email]>:

> Hi!
>
> On Wed, Dec 14, 2011 at 04:27:45PM +0100, Javier Juan Martínez Cabezón wrote:
>> I told you, with a secure TPE (so scripts fully controlled) tell me
>> how to write one kernel exploit under bash without calling external
>> code.
>
> How about
>    $ perl -e 'exploit code here'
> or just
>    $ perl
>    exploit code here from stdin
>    Ctrl-D
> ?
> Is your current RBAC configuration prevent this?
>
> As for me, I tend to agree with you about RBAC, but I think to make RBAC
> really useful it rules/roles must be provided by software developers -
> just like they now provide README and Makefile, because only software
> authors actually know which files, devices and syscalls used by their
> applications and how these requirements change from version to version.
>
> I've tried different RBAC implementations few times, but got tired fixing
> roles and rules - on usual hardened workstation after enabling RBAC (even
> after auto-learning mode) everything become broken in many unexpected
> ways, and it took too many time to realize each time this isn't a bug in
> some software but just RBAC misconfiguration and fixing it. Probably
> workstation isn't good place for RBAC. But on most of my servers there are
> a lot of perl scripts, and we often add new scripts, and writing RBAC
> rules for all of them looks too complicated. Another server must have php,
> ftp, many wordpress sites and other php crap - and I can't even imagine
> how this can be secured using RBAC.
>
> BTW, while I agree with you about useless 'noexec' for /tmp, it's usually
> cheap way to stop few scriptkiddies with default exploits, so there is no
> harm in using it. And no real harm in don't using it.
>
> --
>                        WBR, Alex.
>

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
In reply to this post by Javier Juan Martinez Cabezon
On Wed, 14 Dec 2011 16:27:45 +0100
Javier Juan Martínez Cabezón wrote:

When I have more time I promise to hunt the references out and send
them to you.

> I have never said to eliminate DAC. I just told that ONLY DAC as
> openbsd do is a bad option and insecure.
> You can substitute DAC with RBAC (and RSBAC gives an option to do it).
>
> Now DAC and RBAC are layered, RBAC can be secure without DAC, DAC
> WOULD NEVER be secure without RBAC.

Let's play your game as you keep mixing up contexts and you're the one
making blanket statements not me and telling me you know what I know
better than myself. I merely said that methods of breaking RBAC have
been discussed and a kernel exploit is one of them.

So show me how you can break out of the default apache on OpenBSD then?

>> There is no way that a rootkit could access to kernel memory,
>> /dev/mem, ioports an alike devices are fully controlled and module
>> interfaz too and kernel sources too. Tell me how the hell can anyone
>> launch a ring 0 rootkit, and give proofs as I did a not simple search
>> in grsec or openbsd sites.

>> RBAC IS the kernel,
>>

RBAC is part of the kernel yes and so stored in memory. It is also a
part of the kernel that is meant to be switchable. An exploit in the
kernel can not only bypass RBAC or switch it off it can even situate a
rootkit above the kernel leaving RBAC in place and having ALL rights
aka the root of the system. Yes a perfect policy may prevent an exploit
but it's equally possible that a perfect policy has to allow the
exploit for desired functionality.

The question is what is more important, keeping attackers out or making
sure your policies are good enough to stop them. I prefer OpenBSD for
many reasons aside from just this anyway.

You turned this into a bashing of OpenBSD and I'm not sure anyone here
appreciates the hijacking of this thread, I should have known better
than to mention OpenBSD here and almost removed it before sending, lets
stop and agree to disagree. It's not the first time the importance of
RBACs bug exploitation prevention versus bug removal and prevention at
source has been discussed. Hopefully one day the Linux kernel will be
as bug free and capable to be safely as static as OpenBSDs, I also hope
OpenBSD gets a MAC one day too. Unfortunately I can't see either
happening.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

Javier Juan Martinez Cabezon



Let's play your game as you keep mixing up contexts and you're the one
making blanket statements not me and telling me you know what I know
better than myself. I merely said that methods of breaking RBAC have
been discussed and a kernel exploit is one of them.

I haven't seen no methods in your mails of breaking nothing, only search in the web ones.
 
So show me how you can break out of the default apache on OpenBSD then?

With a bug in the portion of code with privileges. But it's not needed, any bug in any software (as ports that are not audited) that gets root in openbsd can kill apache process, but yeah it's clear that is nearly impossible to get a remote hole in coreutils because they audit his code.....

 


RBAC is part of the kernel yes and so stored in memory. It is also a
part of the kernel that is meant to be switchable. An exploit in the
kernel can not only bypass RBAC or switch it off it can even situate a
rootkit above the kernel leaving RBAC in place and having ALL rights
aka the root of the system. Yes a perfect policy may prevent an exploit
but it's equally possible that a perfect policy has to allow the
exploit for desired functionality.

What do you think that grsec and rsbac is SELinux alike?, Brad Spender prove that selinux could be disabled because his stupid architecture of LSM with exported symbols, grsec and rsbac doesn't work at the horrible way that selinux does and has every code in main code everywhere, there is not a magic button "switch_off" as SELINUX.  Grsec and Rsbac are not a part of the kernel are the kernel itself. In rsbac every syscalls are intercepted, any open(O_RDLY) calls done is intercepted and "substitute" by an READ_OPEN request that should be granted to work, the portion of code that has open calls has the rsbac calls ones there.

Can you patch the kernel on the fly without accessing devices? or without modules interface? or without using ioports interface? just using syscall interface? prove it, but don't get surprised if you get your funny process killed because trying ring 0 changes from ring 3 is strictly forbidden through it, supervisor mode is called I think...

If you can do it you can do then drivers from userspace without glue kernel layer as fuse does (yes in your information is needed a kernel interface to make it work, you can't do directly ring 0 interfaces with only userspace code...
 

The question is what is more important, keeping attackers out or making
sure your policies are good enough to stop them. I prefer OpenBSD for
many reasons aside from just this anyway.

At first sight it seems that you only want to make publicy of openbsd in a gentoo hardened mailing list in a thread of a user that asks explicetly to suggestions about it, at least with my answers he could check rbac data and could save something from them. With yours answers I don't know what can he take in clear.

You turned this into a bashing of OpenBSD and I'm not sure anyone here
appreciates the hijacking of this thread, I should have known better
than to mention OpenBSD here and almost removed it before sending, lets
stop and agree to disagree. It's not the first time the importance of
RBACs bug exploitation prevention versus bug removal and prevention at
source has been discussed. Hopefully one day the Linux kernel will be
as bug free and capable to be safely as static as OpenBSDs, I also hope
OpenBSD gets a MAC one day too. Unfortunately I can't see either
happening.

I only correct your mistakes and try to avoid that the user gets confused by you,
I have been all the thread showing that you noexec implemention does not work and exposed the reason about this and probable solutions. If you are blind about this don't try to extend your blindness to the user that wants suggestions.

Reply | Threaded
Open this post in threaded view
|

Re: New Server, considering hardened, need pointers to tfm...

ma1l1ists
Javier Juan Martínez Cabezón wrote:

> there is not
> a magic button "switch_off" as SELINUX.

and yet previously

>> UID 0 can't switch off nothing only role admin can do it, and usually
>> is not UID 0, in rsbac is UID 400.

>> DAC WOULD NEVER be secure without RBAC.

and yet this is DAC with chroot

> but yeah it's clear that is nearly
> impossible to get a remote hole in coreutils because they audit his
> code.....

> I only correct your mistakes and try to avoid that the user gets
> confused by you,
> I have been all the thread showing that you noexec implemention does not
> work and exposed the reason about this and probable solutions. If you
> are blind about this don't try to extend your blindness to the user
> that wants suggestions.

It is dismissive people like you giving excuses to developers to lower
the default security of Linux for all those desktops who can't spend
time on security and for which noexec would and could have prevented
exploits from downloads to the home directory and from usbs and so udev
potentially violating companies policies of users not running arbitrary
windows programs.

I certainly can't see an end user editing selinux or rsbac and a small
chance of apparmor or rbac in order to run Enemy Territory Quake Wars
or whatever "backlash" reverted noexec from the default mount options.

noexec could have immediately quashed the rubbish like "linux is
vulnerable to viruses too" publicity when the ld.so bug was found,
potentially keeping some on windows.

noexec is not useless and I maintain that arbitrary C code is far more
dangerous than perl or shell. It would also be rediculously easy
for script interpreters to check for noexec and die, heck a wrapper that
checked and changed the egid then allowing perl execution could do it.

"Maybe it is pointless because of usbonthego and all the past bugs in
the usb code upon insertions" (sarcasm)

It is no coincidence that most successful attacks come from phishing
and duplicated passwords. A far cry from RSBAC.

If anyone is misleading anyone, it is you. OpenBSD works for
itself (developers), it does not care even about it's users, if I was
trying to get people to use it, I would and could have come up with
chapters, in fact I stopped myself and have again now. I wouldn't do
that, I don't have time to do that and respect the gentoo hardened
community, the only things I have mentioned are ones that I would like
Linux developers to take note of such as bug reduction in the Linux
kernel and making it easier to track them. OpenBSD is a big part of my
life and so it is bound to slip out when offering advice.

Have you ever disabled ipv6? We could certainly do with ipv5 (just more
addresses)

As you seem to have spent time developing your RSBAC policies and if
you have spent time with grsecs rbac. I would be interested in what you
see makes rsbac worth that extra time over grsec rbac and any good
documents for using them. It seems to me that rsbac is more robust but
takes more time to develop the policies.

Kc

12