| 1 |
Javier Juan Martínez Cabezón wrote: |
| 2 |
|
| 3 |
> there is not |
| 4 |
> a magic button "switch_off" as SELINUX. |
| 5 |
|
| 6 |
and yet previously |
| 7 |
|
| 8 |
>> UID 0 can't switch off nothing only role admin can do it, and usually |
| 9 |
>> is not UID 0, in rsbac is UID 400. |
| 10 |
|
| 11 |
>> DAC WOULD NEVER be secure without RBAC. |
| 12 |
|
| 13 |
and yet this is DAC with chroot |
| 14 |
|
| 15 |
> but yeah it's clear that is nearly |
| 16 |
> impossible to get a remote hole in coreutils because they audit his |
| 17 |
> code..... |
| 18 |
|
| 19 |
> I only correct your mistakes and try to avoid that the user gets |
| 20 |
> confused by you, |
| 21 |
> I have been all the thread showing that you noexec implemention does not |
| 22 |
> work and exposed the reason about this and probable solutions. If you |
| 23 |
> are blind about this don't try to extend your blindness to the user |
| 24 |
> that wants suggestions. |
| 25 |
|
| 26 |
It is dismissive people like you giving excuses to developers to lower |
| 27 |
the default security of Linux for all those desktops who can't spend |
| 28 |
time on security and for which noexec would and could have prevented |
| 29 |
exploits from downloads to the home directory and from usbs and so udev |
| 30 |
potentially violating companies policies of users not running arbitrary |
| 31 |
windows programs. |
| 32 |
|
| 33 |
I certainly can't see an end user editing selinux or rsbac and a small |
| 34 |
chance of apparmor or rbac in order to run Enemy Territory Quake Wars |
| 35 |
or whatever "backlash" reverted noexec from the default mount options. |
| 36 |
|
| 37 |
noexec could have immediately quashed the rubbish like "linux is |
| 38 |
vulnerable to viruses too" publicity when the ld.so bug was found, |
| 39 |
potentially keeping some on windows. |
| 40 |
|
| 41 |
noexec is not useless and I maintain that arbitrary C code is far more |
| 42 |
dangerous than perl or shell. It would also be rediculously easy |
| 43 |
for script interpreters to check for noexec and die, heck a wrapper that |
| 44 |
checked and changed the egid then allowing perl execution could do it. |
| 45 |
|
| 46 |
"Maybe it is pointless because of usbonthego and all the past bugs in |
| 47 |
the usb code upon insertions" (sarcasm) |
| 48 |
|
| 49 |
It is no coincidence that most successful attacks come from phishing |
| 50 |
and duplicated passwords. A far cry from RSBAC. |
| 51 |
|
| 52 |
If anyone is misleading anyone, it is you. OpenBSD works for |
| 53 |
itself (developers), it does not care even about it's users, if I was |
| 54 |
trying to get people to use it, I would and could have come up with |
| 55 |
chapters, in fact I stopped myself and have again now. I wouldn't do |
| 56 |
that, I don't have time to do that and respect the gentoo hardened |
| 57 |
community, the only things I have mentioned are ones that I would like |
| 58 |
Linux developers to take note of such as bug reduction in the Linux |
| 59 |
kernel and making it easier to track them. OpenBSD is a big part of my |
| 60 |
life and so it is bound to slip out when offering advice. |
| 61 |
|
| 62 |
Have you ever disabled ipv6? We could certainly do with ipv5 (just more |
| 63 |
addresses) |
| 64 |
|
| 65 |
As you seem to have spent time developing your RSBAC policies and if |
| 66 |
you have spent time with grsecs rbac. I would be interested in what you |
| 67 |
see makes rsbac worth that extra time over grsec rbac and any good |
| 68 |
documents for using them. It seems to me that rsbac is more robust but |
| 69 |
takes more time to develop the policies. |
| 70 |
|
| 71 |
Kc |
Archives