On Oct 18, 2008, at 4:41 PM, Kyle wrote:
> William,
>
> Do you think that in the meantime Sage could be setup without any
> shell access? I always wondered why any Joe Schmoe could log in, and
> run arbitrary shell commands... Can 'sh' be disabled? Perhaps Sage
> should be running in a chroot jail?
Sage was run inside a chroot jail, but of course that alone isn't
enough to prevent abuse of resources. The talk of hosting sage
servers in virtual machines should be at least as secure, and
probably much easier to administer and maintain.
> Sadly, the easiest way the cracker could have taken the machine down
> was this one-liner:
>
> bash :(){ :|:& };:
>
> And within sh
>
> $0 & $0
>
> I'm not sure how many processes a typical a user is expected to have,
> but the machines could be set up with a hard limit:
>
> Within /etc/security/limits.conf, put the line:
>
> lars hard nproc 40
>
> Then all non-root users will only be allowed to have 40 processes.
> They won't be able to request more than 40 with this as well:
>
> $ ulimit -u 100
>
> -bash: ulimit: max user processes: cannot modify limit: Operation not
> permitted
>
> That may solve the issue of forkbombs, but allowing shell access gives
> rise to other security issues.
Yes, we should have had a number of processes ulimit. Up until now,
we've mostly been relying on the benevolence of users and the fact
that there's little motivation to take down the servers other than
pure meanness or spite or "to prove that they can," which worked very
well for over a year but apparently is not enough. Unfortunately its
the thousands of users that didn't abuse the system that are paying
for it by having the notebooks down.
> Using vulnerabilities in other
> products, a user could escalate their privileges to a root user. In my
> opinion, shell access is the issue.
>
> Of course, a user can still access shell commands through python as
> well, so restricting sh won't solve this either.
Trying to disable shell access through Python would be an extremely
difficult, if not impossible, task, and of course Python is powerful
enough there are ways to wreck havoc without even leaving Python.
Even worse than shell access, we give access to the full gcc pipeline
through cython. On top of that, much of Sage's functionality relies
on the ability to start and communicate with other processes like
maxima and gap. Any tenable security system would almost certainly
have to come from sandboxing and controlling the entire environment
externally, and fortunately there are tools to do so.
> Anyway, thanks for making and continuing development on Sage. I
> absolutely love it. I've been using it for Abstract Algebra all
> semester. Perhaps I'll learn enough that I can make contributions as
> well sometime.
I'm glad you're finding it useful--I wish something like this existed
when I was taking Abstract Algebra. The barrier between using and
developing Sage is as low as I have seen for any open source project,
so hopefully we'll see patches from you someday too.
- Robert
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
