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