Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <1496e27c-7870-48d2-afb0-1bf626e24b5f@googlegroups.com>
References: <20a49aac-3867-481f-96d4-c95a050781ed@googlegroups.com> <CAMw+j7J=ibDTi9c9dxjx_=zuoecFxLawP2KmGjbhBztEC1nWZA@mail.gmail.com> <CAPTjJmrZH1qC=X+LNenXyReNjQT4FmVTKqL24H0D0An0XK9kAg@mail.gmail.com> <mailman.2656.1370359764.3114.python-list@python.org> <592c84d8-2e86-4480-b784-c3ccadc8360d@googlegroups.com> <mailman.2666.1370365761.3114.python-list@python.org> <06fd6c2e-0979-4d61-b75a-6d9df7c1b624@googlegroups.com> <mailman.2688.1370383955.3114.python-list@python.org> <70390d65-5313-46bf-8110-b25f5fc9f76f@googlegroups.com> <mailman.2706.1370419798.3114.python-list@python.org> <8d52505a-7252-419b-8b4f-61e5ee56a78a@googlegroups.com> <mailman.2707.1370421723.3114.python-list@python.org> <2aef9194-ef36-45db-8c77-9510d3f14ebe@googlegroups.com> <mailman.2710.1370423500.3114.python-list@python.org> <c49345c2-7dd8-4b59-9f5c-c4e7ce7a3ea0@googlegroups.com> <mailman.2721.1370428837.3114.python-list@python.org> <8df8a9df-dbb9-4f35-a6a3-b45aa32a848b@googlegroups.com> <mailman.2722.1370430879.3114.python-list@python.org> <1496e27c-7870-48d2-afb0-1bf626e24b5f@googlegroups.com>
Date: Thu, 6 Jun 2013 02:33:50 +1000
Subject: Re: Apache and suexec issue that wont let me run my python script
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2743.1370450038.3114.python-list@python.org>
Lines: 57
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:47107

On Wed, Jun 5, 2013 at 9:19 PM, =CD=E9=EA=FC=EB=E1=EF=F2 =CA=EF=FD=F1=E1=F2=
 <nikos.gr33k@gmail.com> wrote:
> =D4=E7 =D4=E5=F4=DC=F1=F4=E7, 5 =C9=EF=F5=ED=DF=EF=F5 2013 2:14:34 =EC.=
=EC. UTC+3, =EF =F7=F1=DE=F3=F4=E7=F2 Heiko Wundram =DD=E3=F1=E1=F8=E5:
>> Am 05.06.2013 13:07, schrieb =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD:
>>
>> >Btw, since history doesnt show me his history comamnds when he logged i=
n
>> >from .au(why not really?), how can i tell what exactly did he do when h=
e
>> >logged on to the server?
>
>> As root has full access to your system (i.e., can change file contents
>> and system state at will), and you gave him root access: you can't. And
>> he made sure to remove things such as .bash_history and the syslog
>> contents, I guess. At least that's what I'd have done to prove a point.

In fact, I didn't even bother fiddling with syslog. All I did was
.bash_history. Of course, I wasn't worried about you getting my IP
addresses (one of them is public anyway, and the other isn't mine any
longer than I'm using it), and nothing I did there was sufficiently
serious to be worth hiding, but I just did the history so I could
point out how easy this is.

> I see. Thanks.
> Is there some logging utility i can use next time iam offering root acces=
s to someone(if i do it) or perhaps logging a normal's account activity?

You could log a normal user fairly easily, because root trumps normal
users. To log root access, there are a few options:

1) Don't actually give unrestricted roots, but require the use of
sudo, which logs. Not 100% perfect unless you actually restrict the
commands that can be executed, but it'd at least let you have some
idea that things were tampered with.

2) Provide a special bouncer. This is a little complex to describe, so
bear with me. Imagine you have *two* computers, WebHost and Bouncer.
You want to give root access to WebHost, so you invite someone to ssh
to webroot@bouncer - the shell of that user establishes a secondary
connection to root@webhost and passes everything on, but also logs it.
Since *no* access to Bouncer has been granted, the logs can't be
tampered with. This can be complicated to set up and secure, but it's
certainly possible. However, I think it is beyond your ability, at
least at the moment.

3) Provide a hacked-up root shell that logs to a network location, and
disable all other shell usage. Imperfect but would probably work.

4) Require that all root shell access be done through screen/tmux, and
monitor it.

You can probably think of a few others, too.

ChrisA