[DGD] Kernerl security without guest programmers

[Raymond Jennings]

On Tue, Jan 31, 2017 at 12:31 PM, Gary <gary at mups.co.uk> wrote:

> On 31/01/17 10:17, Felix A. Croes wrote:
> > Gary <gary at mups.co.uk> wrote:
> > The kernel library provides creator/owner-based security, using it to
> > restrict file access and some potentially dangerous functionality.  It
> > is not quite clear to me whether you are talking about dismantling this
> > system, or about following the example set by the kernel library for
> > your own code.
> >
>
> It's about following the example for my own code. I do not plan to make
> any modifications to the kernel library and so far have not seen any
> real need to.
>
> I expect the answer to my original question is very much "it depends".
> To give a more explicit example though, I'm current adding a
> /sys/accountd.c daemon to track user's passwords and other account info.
>
> Accountd will likely have a function to find_account(string user) that
> will return that users account info. This method could as the first line
> of code have
>
> object find_account(string user)
> {
>   if (! SYSTEM())
>     return nil;
>
>   ...
> }
>

For this I vastly prefer causing a runtime error.

In my opinion (tm), code that fails silently when it tries to do something
it isn't supposed to be doing in the first place needs to be fixed, and
flagging an error helps weed these cases out.

To ensure that only objects within /usr/System are able to make use of
> that method and under the assumption those objects are more strongly
> vetted for security flaws.
>
> With guest programmers, that check would be rather critical, otherwise
> any guest could run %code "/sys/accountd"->find_user("foo"). (not to
> mention set_account_info)
>
>

> However, with no guest programmers, no live coding and the only people
> with admin rights being those few admins that also have ssh/filesystem
> access and hence have other ways to subvert the system. I'm less certain
> of the benefit of doing the above.
>
> Programmers will have to put all code through git where it's
> reviewed/accepted/tested and then rolled out to the mud by an admin and
> in general the programmers on the team will be viewed as trusted.
>
>
> Bart touched on a reason to keep adding the checks, in that mistakes
> could be made by any programmer that in turn is exploitable by a user to
> run code. Having plenty of SYSTEM()/KERNEL() and other permission checks
> in place would limit the damage that could cause.
>

This is one reason that the kernel library does NOT grant the same access
to a user's objects as it does to the user itself.  Basic security is done
in the auto object, while special privileges granted only to the user are
done via the kernel wiztool library, which does its checks based on the
owner of the wiztool.

>
> The other reason I can think of is that even though all programmer
> changes go via git, wanting to invoke a method on an object that
> originally only allowed SYSTEM() to call it should set off a red flag
> with the programmer and hopefully have them consider whether their newly
> added code should be calling it as a non system object.
>
> Based on the replies so far, I'll continue adding various callee based
> checks around important sections of code. Just in case. Plus as
> mentioned in my original post, maybe one day someone would want to use
> the code-base with guest programmers. Retro-fitting the extra security
> would be much more painful than just fixing up the odd oversight.
>
> Cheers all,
>
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd