not letting users see other user's executing worksheets

[Jason Grout]

As pointed out here:
http://ask.sagemath.org/question/1089/overview-of-security-and-memory-management,
any user on sagenb.org can easily see other currently executing
worksheets and can modify them, etc. Of course, this is bad.

What if, instead of creating these temporary directories used to execute
worksheets in /tmp, we create the temp directories in /tmp/<SERVERNAME>,
and make /tmp/<SERVERNAME> *not* readable by the restricted user
sagenbws. Then the sagenbws user (i.e., a worksheet user) can not list
other currently executing worksheet directories, so we get at least some
level of protection/obfuscation.

What do people think?

Thanks,

Jason

[Jeroen Demeyer]

On 2012-01-24 16:56, Jason Grout wrote:
> What if, instead of creating these temporary directories used to execute
> worksheets in /tmp, we create the temp directories in /tmp/<SERVERNAME>,
> and make /tmp/<SERVERNAME> *not* readable by the restricted user
> sagenbws. Then the sagenbws user (i.e., a worksheet user) can not list
> other currently executing worksheet directories, so we get at least some
> level of protection/obfuscation.
>
> What do people think?

That would work. You also need to make sure the directory is owned by
the server process. I guess permissions should be octal 1733 (rwx-wx-wt).

See also http://trac.sagemath.org/sage_trac/ticket/11679 which is related.

[Keshav Kini]

Speaking of security issues, couldn't any user of sagenb just run `killall python` to reset everyone else's currently running worksheets? (I haven't tried.)

-Keshav

----
Join us in #sagemath on irc.freenode.net !

[William Stein]

On Tue, Jan 24, 2012 at 9:09 AM, Keshav Kini <kesha...@gmail.com> wrote:
> Speaking of security issues, couldn't any user of sagenb just run `killall
> python` to reset everyone else's currently running worksheets? (I haven't
> tried.)

Yep.

>
> -Keshav
>
> ----
> Join us in #sagemath on irc.freenode.net !

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Jason Grout]

On 1/24/12 11:09 AM, Keshav Kini wrote:
> Speaking of security issues, couldn't any user of sagenb just run
> `killall python` to reset everyone else's currently running worksheets?
> (I haven't tried.)

Sysadmin guys: any idea how to protect against something like this? It
also takes down the Sage cell server workers, of course.

It'd be nice if unix somehow had ad-hoc accounts, like a one-time login.
Surely something like that exists somewhere.

Thanks,

Jason

[William Stein]

The sage notebook already has support for dealing with this, where one
can setup a "server pool" with a few hundred accounts that get rotated
through. Since there are never more than "a few hundred" users at
once, this would work fine.
I just didn't configure sagenb that way, since I consider this a very
temporary setup, and will be switching back to remove
virtual machine(s) soon anyways.

-- William

>
> Thanks,
>
> Jason

[Jason Grout]

On 1/24/12 11:52 AM, William Stein wrote:
> On Tue, Jan 24, 2012 at 9:50 AM, Jason Grout
> <jason...@creativetrax.com> wrote:
>> On 1/24/12 11:09 AM, Keshav Kini wrote:
>>>
>>> Speaking of security issues, couldn't any user of sagenb just run
>>> `killall python` to reset everyone else's currently running worksheets?
>>> (I haven't tried.)
>>
>>
>> Sysadmin guys: any idea how to protect against something like this? It also
>> takes down the Sage cell server workers, of course.
>>
>> It'd be nice if unix somehow had ad-hoc accounts, like a one-time login.
>> Surely something like that exists somewhere.
>
> The sage notebook already has support for dealing with this, where one
> can setup a "server pool" with a few hundred accounts that get rotated
> through. Since there are never more than "a few hundred" users at
> once, this would work fine.
> I just didn't configure sagenb that way, since I consider this a very
> temporary setup, and will be switching back to remove
> virtual machine(s) soon anyways.

That's a workaround for the real problem that worksheets pull from the
same pool of unix accounts. It'd be nice if there was already a way to
solve the underlying problem by ensuring that all worksheets were always
distinct "guest" users.

Thanks,

Jason

[William Stein]

On Tue, Jan 24, 2012 at 9:58 AM, Jason Grout

It would ensure that as long as the number of accounts in the pool
exceeds the number of simultaneous logins. It would be easy to
automatically create, e.g., ten thousand accounts, and put them in a
server pool, then limit the number of simultaneous users to 10000.

-- william

[Jason Grout]

And after searching for a few minutes, I can't find any pre-built
solutions to allow thousands or tens of thousands temporary guest
accounts that are added/deleted on the fly. So yeah, what you said
sounds like the best solution at this point. Especially since there is
a very real upper bound to the number of simultaneous users in a Sage
server.

We need to deal with this with the Sage cell server, which works by
forking a single Sage process for instant worksheet startup time. We'll
have to change the userid for the process after we fork it to one of
these pooled accounts.

Thanks,

Jason

[Jeroen Demeyer]

On 2012-01-24 19:10, Jason Grout wrote:
> And after searching for a few minutes, I can't find any pre-built
> solutions to allow thousands or tens of thousands temporary guest
> accounts that are added/deleted on the fly.

One thing you could do in Unix is to use anonymous user IDs, user IDs
without a name. But this would probably break stuff. Also, it's hard
to determine that a user ID is really not in use, or to prevent it
becoming used in the future.