On Sat, Oct 18, 2008 at 7:41 PM, Kyle <[EMAIL PROTECTED]> 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?
>
Python comes with the os module. Sage was ran in a chroot jail and
security was such that an attacker couldn't mess with stored data for
users, worksheets, etc.
> Sadly, the easiest way the cracker could have taken the machine down
> was this one-liner:
>
> bash :(){ :|:& };:
>
> And within sh
>
> $0 & $0
See Wikipedia for the simple Python script.
>
> 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. 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.
>
> 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.
>
>
> -- Kyle
>
> On Oct 15, 1:14 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>> On Tue, Oct 14, 2008 at 8:26 PM, Jason Grout
>>
>>
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>> >> Actually, the concept Timothy is talking about is true. The framework
>> >> for running notebook processes in Knoboo is very different from what
>> >> Sage does to serve notebooks. Indeed, the machine running actual
>> >> notebook processes (or engine processes as we call them) is considered
>> >> history in this situation, however, access to the notebook data would be
>> >> absolutely un-affected -- an important point -- because users *can*
>> >> still view/download their notebook data as it is maintained by an
>> >> entirely separate system running on a physically separated machine. Not
>> >> to be nit-picky, but this is very attractive from a user perspective;
>> >> it's not as catastrophic as the entire service disappearing (like what's
>> >> happening now).
>>
>> > If I understand things correctly, the biggest obstacle to Sage doing
>> > this currently is that the client processes expect to be able to read
>> > and write the notebook files (the files associated with the cells in the
>> > notebook) and theserverexpects the output to automatically appear in
>> > the correct cell directory. Is that correct?
>>
>> Yes. In fact, as long as you have a shared filesystem for both machines,
>> you can *already* run the worker processes on a different real or
>> virtual machine.
>>
>> -- William
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
