From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <40745EA5-3815-4E4F-9FE0-8F83697E74BA@bitblocks.com> <1e801ae2-0d18-4df9-a9a7-ec6480b9b6aa@www.fastmail.com> <02669859-3065-478A-AC9E-2C921976A745@gmail.com> <115a2abc-2231-4492-be26-8e8f7f133559@www.fastmail.com> In-Reply-To: <115a2abc-2231-4492-be26-8e8f7f133559@www.fastmail.com> From: Don Bailey Date: Fri, 23 Aug 2019 13:41:44 -0600 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000a8c6dc0590cdff51" Subject: Re: [9fans] Plan 9 security Topicbox-Message-UUID: 066acdc0-eada-11e9-9d60-3106f5b1d025 --000000000000a8c6dc0590cdff51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 23, 2019 at 12:47 PM Ethan Gardener wrote= : > On Tue, Aug 20, 2019, at 2:29 PM, Don A. Bailey wrote: > > > > Fwiw Plan 9=E2=80=99s code vase has indeed been audited. By me. Several > exploitable bugs were found including a kernel exploit due to the env > driver. I wrote a working PoC for it which is somewhere on the internet, > but it=E2=80=99s quite old. > > My apologies! > No apologies necessary, you didn't know. > > > Much of the code hasn=E2=80=99t changed, and, I would suspect, is large= ly secure. > > Good to know. :) > > I wonder how many relevant parts have changed in 9front? There are > regular kernel changes, some of which were made to handle the heavy > shell-script load of running werc sites. (For a short time, the load on > cat-v.org was very heavy.) > > A delta audit would be useful and might be fun. I don't think I have the time, currently, but I wouldn't mind to get back into it. > > But you=E2=80=99re talking implementation security versus architectural > security. In the case of IoT, Plan 9 does exceptional things to close the > gaps that embedded systems supply its users, but it is nowhere near > complete. > > I guess I am, and yes, Plan 9 is sadly incomplete in many areas. > I don't think it's sadly incomplete. Plan 9 is awesome. However, it isn't really Plan 9's job to address silicon security and hardware trust. Some integrations could be made into the kernel authentication stack and the Secure Store et. al., but that is a gap easily closed. The hard part is choosing cost effective hardware that does the job. The Linux BIOS team (Ron and Pals) have done a great job of getting closer to The Source, but that isn't really something an OS should address. That's more of a firmware/BIOS/CPU thing. --000000000000a8c6dc0590cdff51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 23, 2019 at 12:47 PM Etha= n Gardener <eekee57@fastmail.fm> wrote:
On= Tue, Aug 20, 2019, at 2:29 PM, Don A. Bailey wrote:
>
> Fwiw Plan 9=E2=80=99s code vase has indeed been audited. By me. Severa= l exploitable bugs were found including a kernel exploit due to the env dri= ver. I wrote a working PoC for it which is somewhere on the internet, but i= t=E2=80=99s quite old.

My apologies!


> Much of the code hasn=E2=80=99t changed, and, I would suspect, is larg= ely secure.

Good to know. :)

I wonder how many relevant parts have changed in 9front?=C2=A0 There are re= gular kernel changes, some of which were made to handle the heavy shell-scr= ipt load of running werc sites.=C2=A0 (For a short time, the load on cat-v.org w= as very heavy.)


A delta audit would be useful and migh= t be fun. I don't think I have the time, currently, but I wouldn't = mind to get back into it.=C2=A0
=C2=A0
> But you=E2=80=99re talking implementation security versus architectura= l security. In the case of IoT, Plan 9 does exceptional things to close the= gaps that embedded systems supply its users, but it is nowhere near comple= te.

I guess I am, and yes, Plan 9 is sadly incomplete in many areas.=C2=A0
=

I don't think it's sadly incomplet= e. Plan 9 is awesome. However, it isn't really Plan 9's job to addr= ess silicon security and hardware trust. Some integrations could be made in= to the kernel authentication stack and the Secure Store et. al., but that i= s a gap easily closed. The hard part is choosing cost effective hardware th= at does the job. The Linux BIOS team (Ron and Pals) have done a great job o= f getting closer to The Source, but that isn't really something an OS s= hould address. That's more of a firmware/BIOS/CPU thing.=C2=A0


=C2=A0
--000000000000a8c6dc0590cdff51--