"chroot is not a security tool"
boo...@u.washington.edu
http://kerneltrap.org/Linux/Abusing_chroot
The gist: root can trivially break out of the chroot "jail" -- and is then the superuser on the system. I'm not a security expert, but this sounds only locking the driver's door of a car, and leaving a key on the dash: if a user can escalate to root in the jail, they root the box.
Another slashdot article today made me think about this again:
http://computerworld.co.nz/news.nsf/scrt/CD0B9D97EE6FE411CC25736A000E4723
Sure, windows is insecure. But n00bs like me doing security is insecure no matter what operating system they use. If the notebook isn't secure, and Sage achieves the BDFL's primary goal, then we'll become a major contributor to the online efforts of organized crime and spam.
So: what can we use instead? VMWare? UML? SELinux in VMWare running under UML? Or, will we have to stop executing arbitrary code by unknown public entities again? (I really hate the last option)
Juan M. Bello Rivas
On Fri, Oct 05, 2007 at 11:45:46AM -0700, boo...@u.washington.edu wrote:
> So: what can we use instead? VMWare? UML? SELinux in VMWare running under UML? Or, will we have to stop executing arbitrary code by unknown public entities again? (I really hate the last option)
Using Pypy's sandboxing capabilities might be an option (I haven't
tried this myself):
http://codespeak.net/pypy
http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
--
Juan M. Bello Rivas
Timothy Clemans
this is a big deal. The public notebooks are not ran with superuser
privileges. If I remember right one has to use a process with
superuser privileges and make it pawn a new jail.
It is already for someone to make any public worksheet undownloadable.
I can't find the e-mail where I wrote a basic report about it.
Robert Bradshaw
that are actually meant for security that one might want to look
into. BSD has some jail stuff if I recall correctly.
I don't think PyPy would work, given the ability to use compiled code
from SAGE. (SAGE might not even run under PyPy due to all the Cython
code).
It should be noted that one requires a local privilege escalation to
break out of chroot (though those are certainly not unheard of).
- Robert
mabshoff
On Oct 5, 9:45 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> I'm not an expert on this, but there are other "jails" than chroot
> that are actually meant for security that one might want to look
> into. BSD has some jail stuff if I recall correctly.
>
> I don't think PyPy would work, given the ability to use compiled code
> from SAGE. (SAGE might not even run under PyPy due to all the Cython
> code).
>
> It should be noted that one requires a local privilege escalation to
> break out of chroot (though those are certainly not unheard of).
The problem is that admins don't take local privilege escalation
seriously, but just look lkml or some security related list and check
out the uptime on your box. Chances are that you are in trouble. On
top of that Sage offers the capability to compile code from the
notebook and that is just like painting a big red bull's eyes on your
back. As stated above chroot is not a security tool and once you are
root even in chroot things are basically over. I have conjectured that
access to a shell account + time results in root as long as you pay
attention. Having a kernel patched against all known local privilege
escalation has saved me on more than on one occasion when servers I
did administrated got hit by some 0-day exploit via php/Apache/you
name it.
And since XEN and all over virtualisation solutions have bugs, too, it
is very hard to keep a bix with shell access secure. For a really
amusing bug about XEN and priviledge escalation see
http://secwatch.org/advisories/1019097/
Cheers,
Michael
>
> - Robert
>
> On Oct 5, 2007, at 12:14 PM, Juan M. Bello Rivas wrote:
>
> > Hi,
>
> > On Fri, Oct 05, 2007 at 11:45:46AM -0700, boot...@u.washington.edu
Michel
I used a command like this (as root)
/usr/sbin/chroot chroot_directory su - sage -c "sage -c \"$COMMAND\" "
Thus the sage process inside the chroot is run by a user "sage".
I am not sure how secure this is. Any ideas?
Michel
On Oct 5, 8:45 pm, boot...@u.washington.edu wrote:
> This was posted to slashdot sometime last week:
>
> http://kerneltrap.org/Linux/Abusing_chroot
>
> The gist: root can trivially break out of the chroot "jail" -- and is then the superuser on the system. I'm not a security expert, but this sounds only locking the driver's door of a car, and leaving a key on the dash: if a user can escalate to root in the jail, they root the box.
>
> Another slashdot article today made me think about this again:
>
> http://computerworld.co.nz/news.nsf/scrt/CD0B9D97EE6FE411CC25736A000E...
mabshoff
On Oct 5, 11:44 pm, Michel <michel.vandenbe...@uhasselt.be> wrote:
Hello Michel,
> I think the trick is not to run the processes in the chroot as root.
No one ever should run the sage process as root. We should seriously
consider adding a check at startup for UID==0 and refuse to start if
that is the case. Running any kind of server with root priviledges is
just plain stupid. If you have to use a port below 1000 you need to at
least drop priviledges.
>
> I used a command like this (as root)
>
> /usr/sbin/chroot chroot_directory su - sage -c "sage -c \"$COMMAND\" "
>
> Thus the sage process inside the chroot is run by a user "sage".
Something like this happens on sage.math, the sage server runs as user
aklemm.
> I am not sure how secure this is. Any ideas?
>
I helps a little, but getting from non-privileged shell to root shell
provided you have compilers isn't very hard. We should just clearly
let people who run public notebooks know that this is something to
keep an eye on. I think William told us late yesterday that he is the
only one running public notebook, but my recollection could be wrong.
Adding SELinux support for Sage is a good way to become more secure,
i.e. a root account without the right priviledges under SELinux acts
just like a user account and we can restrict the Sage user even more.
I have been looking into that, but haven't gotten to the point where I
can submit docs/code because other things have kept me busy in Sage as
well as work-wise.
> Michel
>
Cheers,
Michael
boo...@u.washington.edu
> Until there is a solid exploit for the Sage notebook I don't think
> this is a big deal.
This is the worst software practice to EVER come out of Redmond. You should know better than that. With that attitude, you don't get started on a fix until an exploit has been *discovered* in the wild -- that discovery happens 6 months to a year after release. Then, it'll be another month before a fix is published, and another year to two before the install base (security n00bs like me) get around to upgrading to the secure edition.
By that time, you've cross-infected your entire internal network, and you've assisted spammers and botnets in the infection of hundreds or thousands of other boxen. Read the articles I posted. NONE of the linux admins new that they'd been pwned, months after the fact. That's *scary*.
Timothy Clemans
g = load('/home/server2/nb1/sage_notebook/nb.sobj')
j = g.users()
for i in j.keys():
print g.users()[i]._User__email
On 10/5/07, boo...@u.washington.edu <boo...@u.washington.edu> wrote:
>
mabshoff
On Oct 6, 1:05 am, "Timothy Clemans" <timothy.clem...@gmail.com>
wrote:
> Ok then here is how to collect all the email addresses for users of sagenb.com:
>
> g = load('/home/server2/nb1/sage_notebook/nb.sobj')
> j = g.users()
> for i in j.keys():
> print g.users()[i]._User__email
>
The above doesn't even come close to an exploit, much less a major
one, in my book. And subscribing to any google group nets you plenty
of email addresses to spam, so this seems to be an unlikely target.
Setting up a public Sage notebook is fundamentally about trust and
having a secure change rootable Sage installation lets you just wipe
it clean and restart from a clean state in case there are problems. I
would never run a public notebook because I do not trust users, much
less the general public.
> On 10/5/07, boot...@u.washington.edu <boot...@u.washington.edu> wrote:
>
>
>
> > On Fri, 5 Oct 2007, Timothy Clemans wrote:
>
> > > Until there is a solid exploit for the Sage notebook I don't think
> > > this is a big deal.
>
> > This is the worst software practice to EVER come out of Redmond.
That isn't Redmond only by the way. Just have a look at Oracle
quarterly patches and you should either die laughing or run for the
hills to hide. I know a guy how gets payed to restart an Oracle server
on a very old version of Solaris every 42 days because of some
overflow issues in the software.
>> You should know better than that. With that attitude, you don't get started on a fix until an exploit has been *discovered* in the wild -- that discovery happens 6 months to a year after release. Then, it'll be another month before a fix is published, and another year to two before the install base (security n00bs like me) get around to upgrading to the secure edition.
>
> > By that time, you've cross-infected your entire internal network, and you've assisted spammers and botnets in the infection of hundreds or thousands of other boxen. Read the articles I posted. NONE of the linux admins new that they'd been pwned, months after the fact. That's *scary*.
Yep, the whole "I am not a target" and "Who would think of that"
attitude toward security will get you in trouble. In order to care and
learn about security many people just need to get their virtual pants
pulled down a couple times before they get it.
Cheers,
Michael
Timothy Clemans
> one, in my book. And subscribing to any google group nets you plenty
> of email addresses to spam, so this seems to be an unlikely target.
Actually it is an exploit classified under unauthorised data access
because it is unintended for a random user to discover other users'
emails. Those emails are often linked to other web services such as
MySpace.
mabshoff
On Oct 6, 1:28 am, "Timothy Clemans" <timothy.clem...@gmail.com>
wrote:
> > The above doesn't even come close to an exploit, much less a major
> > one, in my book. And subscribing to any google group nets you plenty
> > of email addresses to spam, so this seems to be an unlikely target.
Hello,
>
> Actually it is an exploit classified under unauthorised data access
Well, I classify that as an information leak, not an exploit. I should
be fixed, but I am not going to do it.
I could root most boxes behind a public Sage notebook and that is what
I call an exploit. But the design of Sage requires a compiler and even
if you crippled Sage by removing the possibility to compile code
because you remove the compiler it takes only minor work to wget a
statically linked gcc installed locally via python's system command.
You can close that hole, too. But Sage's philosophy is about
collaboration and trust and as I pointed out above I wouldn't run a
publically available Sage notebook because I know what jerks are
capable of. So if you care about security don't run a public Sage
notebook without some additional form of authentication, because
securing a public notebook of Sage would turn Sage into something that
is no longer in the spirit of Sage development.
It might be a good idea to ulimit Sage and its child processes in one
way or another so we do not get pari processes that run amok like the
ones William did kill two days ago.
> because it is unintended for a random user to discover other users'
> emails. Those emails are often linked to other web services such as
> MySpace.
I don't get the link to myspace.
Cheers,
Michael
William Stein
> > Actually it is an exploit classified under unauthorised data access
> Well, I classify that as an information leak, not an exploit. I should
> be fixed, but I am not going to do it.
>
> I could root most boxes behind a public Sage notebook and that is what
> I call an exploit. But the design of Sage requires a compiler and even
> if you crippled Sage by removing the possibility to compile code
> because you remove the compiler it takes only minor work to wget a
> statically linked gcc installed locally via python's system command.
> You can close that hole, too. But Sage's philosophy is about
> collaboration and trust and as I pointed out above I wouldn't run a
> publically available Sage notebook because I know what jerks are
> capable of. So if you care about security don't run a public Sage
> notebook without some additional form of authentication, because
> securing a public notebook of Sage would turn Sage into something that
> is no longer in the spirit of Sage development.
>
> It might be a good idea to ulimit Sage and its child processes in one
> way or another so we do not get pari processes that run amok like the
> ones William did kill two days ago.
(1) This is already done. All processes are ulimited in ram usage.
(2) The public Sage notebook is not secure,
I don't think it ever will be and I have illusions
about it being so. I think the only reasonable way to run a public
notebook server in the longrun is on a dedicated machine that
gets books off of a DVD, and only uses the hard disk for storing
worksheets and other data. At some point soon I intend to replace
sagenb.org (which is just a chroot in sage.math.washington.edu) with
a dedicated server.
(3) A simple chmod og-rwx on a few files resolve the
exploit that Timothy C. reported; I've add a note to
the Sage documentation about this. Thanks Timothy!
I do want to hear about all such exploits -- there's no
reason to not document or fix them.
(4) The chroot jail used for sagenb.org serves an additional
purpose besides security. It also keeps the disk space usage of
the notebook under control. Nobody can accidentally create
a large file that messes of sage.math from the chroot.
(5) If Sage becomes much more popular, the public
Sage notebooks will disappear and be replaced
by either advertiser-supported free versions, or subscription
only versions. The current situation -- where they are completely
free in every sense is not long-term sustainable if demand
for the notebooks grows too much --e.g.,, if they get used by
100 people at once they will become useless. If Sage
continues to improve and grow like it is now, this is what wil
likely happen. Whenever "sage dot com" happens, the public
notebooks will be something that entity will have to worry about.
William
mabshoff
On Oct 6, 3:02 am, "William Stein" <wst...@gmail.com> wrote:
> On 10/5/07, mabshoff <Michael.Absh...@fsmath.mathematik.uni-dortmund.de> wrote:
>
>
>
> > > Actually it is an exploit classified under unauthorised data access
> > Well, I classify that as an information leak, not an exploit. I should
> > be fixed, but I am not going to do it.
>
> > I could root most boxes behind a public Sage notebook and that is what
> > I call an exploit. But the design of Sage requires a compiler and even
> > if you crippled Sage by removing the possibility to compile code
> > because you remove the compiler it takes only minor work to wget a
> > statically linked gcc installed locally via python's system command.
> > You can close that hole, too. But Sage's philosophy is about
> > collaboration and trust and as I pointed out above I wouldn't run a
> > publically available Sage notebook because I know what jerks are
> > capable of. So if you care about security don't run a public Sage
> > notebook without some additional form of authentication, because
> > securing a public notebook of Sage would turn Sage into something that
> > is no longer in the spirit of Sage development.
>
> > It might be a good idea to ulimit Sage and its child processes in one
> > way or another so we do not get pari processes that run amok like the
> > ones William did kill two days ago.
>
Hello,
> (1) This is already done. All processes are ulimited in ram usage.
good, but then you should also limit the amount of CPU time to
something reasonable. I have no opinion what reasonable is in this
context ;)
Cheers,
Michael
Michel
>
> I helps a little, but getting from non-privileged shell to root shell
> provided you have compilers isn't very hard.
Do you claim any ordinary user can become root? I.e. that the
unix security model is worthless? Surely this is not what you mean.
Can you clarify?
Regards,
Michel
mabshoff
On Oct 6, 9:27 pm, Michel <michel.vandenbe...@uhasselt.be> wrote:
> > I helps a little, but getting from non-privileged shell to root shell
> > provided you have compilers isn't very hard.
Hello Michel,
>
> Do you claim any ordinary user can become root? I.e. that the
> unix security model is worthless? Surely this is not what you mean.
> Can you clarify?
>
What I mean with that is that with the current frequency of local
exploits reported with common operating systems, be it Linux, Windows,
MacOSX or whatever, the most difficult step is usually getting a local
[unprivileged] shell on the system one tries to penetrate. With a Sage
notebook installed, even in a change root environment, an attacker
already has a fully functioning python interpreter at his/her command
and via "system" a shell. So all it takes is an unpatched local
exploit and the box is pawned, assuming the attack is reasonably
skilled.
In the past many security penetrations for Linux boxen have been
traced to old kernels and usually stolen credentials for non-
privileged user accounts. One prime example was the pawning of a lot
of Debian servers, I am sure the vast majority of breaches are never
reported or at least don't make it into the news. The same applies to
OSX and Windows and to a lesser extend to *BSD and Solaris, mostly
because the skill set to attack *BSD and Solaris is less common these
days.
> Regards,
> Michel
Cheers,
Michael
Chris Chiasson
On Oct 6, 3:43 pm, mabshoff <Michael.Absh...@fsmath.mathematik.uni-
mabshoff
On Oct 7, 12:42 pm, Chris Chiasson <chris.chias...@gmail.com> wrote:
Hello Chris,
> What about a virtualized system for each user?
Sure, that works, but seems to be an extraordinary amount of work to
fix the problem. Down the road at least the public notebook on
sage.math will migrate to its own hardware, so it "solved" the problem
by using another box. If that box ever were to get compromised you
just reinstall from scratch. This problem is mostly hypothetical
because few actually have the skillset to break out of chroot and also
sage is a very small target for now. That will (hopefully) change down
the road and if I were ever motivated to break into a math department
that would be running a public Sage notebook I would certainly know
where to look first. Once you force everybody to use accounts on a
Sage notebook there are easier targets out there.
Cheers,
Michael