<br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let&#39;s play your game as you keep mixing up contexts and you&#39;re the one<br>
making blanket statements not me and telling me you know what I know<br>
better than myself. I merely said that methods of breaking RBAC have<br>
been discussed and a kernel exploit is one of them.<br>
<br></blockquote><div>I haven&#39;t seen no methods in your mails of breaking nothing, only search in the web ones.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

So show me how you can break out of the default apache on OpenBSD then?<br></blockquote><div><br>With a bug in the portion of code with privileges. But it&#39;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&#39;s clear that is nearly impossible to get a remote hole in coreutils because they audit his code.....<br>
<br>  <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
<br></div>
RBAC is part of the kernel yes and so stored in memory. It is also a<br>
part of the kernel that is meant to be switchable. An exploit in the<br>
kernel can not only bypass RBAC or switch it off it can even situate a<br>
rootkit above the kernel leaving RBAC in place and having ALL rights<br>
aka the root of the system. Yes a perfect policy may prevent an exploit<br>
but it&#39;s equally possible that a perfect policy has to allow the<br>
exploit for desired functionality.<br>
<br></blockquote><div>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&#39;t work at the horrible way that selinux does and has every code in main code everywhere, there is not a magic button &quot;switch_off&quot; 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 &quot;substitute&quot; 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.<br>
<br>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&#39;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...<br>
<br>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&#39;t do directly ring 0 interfaces with only userspace code... <br>
 <br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The question is what is more important, keeping attackers out or making<br>
sure your policies are good enough to stop them. I prefer OpenBSD for<br>
many reasons aside from just this anyway.<br>
<br></blockquote><div>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&#39;t know what can he take in clear. <br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You turned this into a bashing of OpenBSD and I&#39;m not sure anyone here<br>
appreciates the hijacking of this thread, I should have known better<br>
than to mention OpenBSD here and almost removed it before sending, lets<br>
stop and agree to disagree. It&#39;s not the first time the importance of<br>
RBACs bug exploitation prevention versus bug removal and prevention at<br>
source has been discussed. Hopefully one day the Linux kernel will be<br>
as bug free and capable to be safely as static as OpenBSDs, I also hope<br>
OpenBSD gets a MAC one day too. Unfortunately I can&#39;t see either<br>
happening.<br></blockquote><div><br>I only correct your mistakes and try to avoid that the user gets confused by you,<br>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&#39;t try to extend your blindness to the user that wants suggestions.<br>
<br></div></div>