[9fans] Security, take 2.

[9fans] Security, take 2.

[Devon H. O'Dell]

Given the feedback from the list, I've come up with two alternatives.
(Well, one of them was actually Mechiel's brainchild).

Idea #1 (From Mechiel)
Instead of doing typed allocations, give every user an allocation
pool, from which all kernel allocations will take place. To extend on
this, the size of the pool is somewhat dynamic -- as new users log in,
all users' ability to consume kernel resources goes down by a fair
percentage. (Except for eve.) As users log out, all users gain the
percentage of resources back. The number is based on a 90% resource
allocation -- i.e. the kernel may keep 10% of its initial resources
for things it needs to do all by itself, without users interfering.
When a malloc occurs with up, that size is stored in a counter. The
proc also holds per-proc information, so that a username change can
intelligently move only the resources from that proc over to the new
user, instead of everything from the old user (which is clearly
wrong).

This implementation has one magic number: 0.9. The fair share is
percentage based from that, but I'm not experience in fair share
algorithms, so maybe there's a better way to do that. Also, the
security of this implementation is provable.

Downside is that this implementation is somewhat intrusive:
introducing 9/port/kreslimit.c and touching 9/port/portdat.h,
9/port/portfns.h, 9/port/alloc.c, 9/port/proc.c, and 9/port/devcap.c

I only have one question about implementation: where in process
creation is the process username set? In newproc(), I see p->user set
to "*nouser"; I can only assume this is `fixed' later, but I don't
know where. I ask, because for natively started processes (i.e. not a
user logging in from drawterm, that's handled through devcap), I need
to incref on the proc structure that holds the user's pool info. I
know I need to do this in e.g. #c/user, and devcap. But when a user
starts a new process after logging in, it needs to add a ref. Where in
proc.c (or elsewhere) is it finally determined who the user is? (Is
that in renameuser()? I wasn't sure).

Idea #2
Implement a similar thing as mult.bsd.lv. This would be implemented as
a device and would give you a `blank' Plan 9 system:
echo {cpushare} {maxmem} {newroot} > /dev/virtual/new

I haven't thought a whole lot about how this would work, but I'm
guessing at least the maxmem would be implemented similarly, by
creating a new pool. I'd have to learn more about the scheduler to do
the CPU limiting, and newroot would be as easy as a bind(). This would
also be somewhat intrusive (but maybe not more so than Kreslimit), but
has hard values, and provable security. (And the advantage of being
able to spawn `new' Plan 9 instances from Plan 9.) More like jail(8)
in FreeBSD (but much cleaner, due to its provability), less like
vkernel(8) in DragonFly BSD.

--dho

Re: [9fans] Security, take 2.

[Alexander Clouter]

Devon H. O'Dell <devon.odell@gmail.com> wrote:
>
> Given the feedback from the list, I've come up with two alternatives.
> (Well, one of them was actually Mechiel's brainchild).
>
> Idea #1 (From Mechiel)
> [snipped]
>
Maybe it's just the packet shifter in me, but could not the ideas of
Token Buckets[1], Random Early Detection[2], Weighted Fair Queuing[3]
and such be applied to memory/cpu resource allocation?

You would have to replace terms like 'bandwidth' with something like
'free memory' but it would end up resulting in a fair system that
usually means fewer knobs for sysadmins to tweak?

Probably the only knobs the sysadin would want to tweak in the end is
resources that would be considered reserved/guarenteed availability[4]
to backplane (aka critical OS-esque) systems?  So you could say "no
matter what a mess some user made of my system, I want to be always able
to get to 10% of the RAM/CPU time".

I can imagine the WFQ being helpful in something that blocks requests
for more memory in chunks of time that grows expotentially with the
amount of memory that has already been allocated.

The win would be you can mix big resource users with the lightweight
ones on the same CPU servers...would you not?  The knobs for tweaking
would be be more to scaling factors rather than limits/caps.

I'll now go back to lurking... :)

Cheers

[1] http://www.opalsoft.net/qos/DS-24.htm
[2] http://www.opalsoft.net/qos/DS-26.htm
[3] http://en.wikipedia.org/wiki/Weighted_fair_queuing
[4] in the packet shifting world it's called Expedited Forwarding (EF)

--
Alexander Clouter
.sigmonster says: What does it mean if there is no fortune for you?

Re: [9fans] Security, take 2.

[Iruata Souza]

On Fri, Apr 17, 2009 at 2:43 PM, Devon H. O'Dell <devon.odell@gmail.com> wrote:
> Given the feedback from the list, I've come up with two alternatives.
> (Well, one of them was actually Mechiel's brainchild).
>
> Idea #1 (From Mechiel)
> Instead of doing typed allocations, give every user an allocation
> pool, from which all kernel allocations will take place. To extend on
> this, the size of the pool is somewhat dynamic -- as new users log in,
> all users' ability to consume kernel resources goes down by a fair
> percentage. (Except for eve.) As users log out, all users gain the
> percentage of resources back. The number is based on a 90% resource
> allocation -- i.e. the kernel may keep 10% of its initial resources
> for things it needs to do all by itself, without users interfering.
> When a malloc occurs with up, that size is stored in a counter. The
> proc also holds per-proc information, so that a username change can
> intelligently move only the resources from that proc over to the new
> user, instead of everything from the old user (which is clearly
> wrong).
>
> This implementation has one magic number: 0.9. The fair share is
> percentage based from that, but I'm not experience in fair share
> algorithms, so maybe there's a better way to do that. Also, the
> security of this implementation is provable.
>
> Downside is that this implementation is somewhat intrusive:
> introducing 9/port/kreslimit.c and touching 9/port/portdat.h,
> 9/port/portfns.h, 9/port/alloc.c, 9/port/proc.c, and 9/port/devcap.c
>
> I only have one question about implementation: where in process
> creation is the process username set? In newproc(), I see p->user set
> to "*nouser"; I can only assume this is `fixed' later, but I don't
> know where. I ask, because for natively started processes (i.e. not a
> user logging in from drawterm, that's handled through devcap), I need
> to incref on the proc structure that holds the user's pool info. I
> know I need to do this in e.g. #c/user, and devcap. But when a user
> starts a new process after logging in, it needs to add a ref. Where in
> proc.c (or elsewhere) is it finally determined who the user is? (Is
> that in renameuser()? I wasn't sure).
>
> Idea #2
> Implement a similar thing as mult.bsd.lv. This would be implemented as
> a device and would give you a `blank' Plan 9 system:
> echo {cpushare} {maxmem} {newroot} > /dev/virtual/new
>
> I haven't thought a whole lot about how this would work, but I'm
> guessing at least the maxmem would be implemented similarly, by
> creating a new pool. I'd have to learn more about the scheduler to do
> the CPU limiting, and newroot would be as easy as a bind(). This would
> also be somewhat intrusive (but maybe not more so than Kreslimit), but
> has hard values, and provable security. (And the advantage of being
> able to spawn `new' Plan 9 instances from Plan 9.) More like jail(8)
> in FreeBSD (but much cleaner, due to its provability), less like
> vkernel(8) in DragonFly BSD.
>
> --dho
>
>

you may want to take a look at Solaris Zones:
http://opensolaris.org/os/community/zones/

iru