[DGD] Kernerl security without guest programmers

[Gary]

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;

  ...
}

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.

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