[Sudoscript-devel] RE: Architecture 2.0

[Morris, A. <AM...@pr...>]

Greetings Howard,

	I'm not entirely sure that we have the same design goals in mind for
both of our versions, so don't let me burden your software with my own...
:-)  I'm not using sudoshell/sudoscriptd and I don't want to install perl
everywhere.  We're not even using sudo yet, but I need something like
sudoshell to be able to persuade management here that it is a better way to
go than their current ($30,000 plus $10,000 p.a.) favoured product.

	My primary goal is to be able to do keystroke logging within a
sudo'd shell.  Obviously sudoshell/sudoscriptd would do that.  

On top of that...

I would like to be able to generate separate log files for each session.
It's easier to find what someone did if I can view a log of the session
without having to split a logfile up, trawl through multiple files, or
filter out irrelevant data.

Some logging should be done through syslog to make it harder for users to
hide their tracks.  Our current product uses a central logging server, but
if the network is down it's useless.

I don't want to have any processes running all the time as (I believe) that
sudo shell access will be a relatively infrequent occurrence.  

I would like to be able to selectively turn logging on and off for users.
i.e. everyone runs their shell through sudo and it only logs those shells
that we actually care about.  This should be done at the "write to logfile"
end of the process so that the user doesn't know if we are recording their
session or not.  This is not yet implemented.

I don't want to have to have perl everywhere.  Not all of our machines have
perl on them and we probably can't put it on all of them.  (I work in a
healthcare organisation and we can't arbitrarily load software on all
machines.)

The software should be relatively small which makes it easier to eyeball and
check that it does what it's supposed to.  So far I have it working within
150 lines.  If I complete what I currently have it should be no more than
200.  Comments included.  Maybe 250 to allow for the check of whether we are
actually wanting the log output.

The single binary version that I have been working on solves most of my
issues cleanly and simply.  It's easy for someone to escape from keystroke
logging but that is true of all keystroke logging that I have seen including
that provided by our current solution.

Adam

-----Original Message-----
From: Howard Owen [mailto:hb...@eg...]
Sent: Thursday, May 09, 2002 11:36 AM
To: Morris, Adam
Cc: 'sud...@li...'
Subject: RE: Architecture 2.0



I'm looking at your single program architecture, Adam.
I'm going to protype it in Perl to see if I can hit all
my design points using a single script.

--On Thursday, May 09, 2002 10:31:26 AM -0700 Howard Owen <hb...@eg...> 
wrote:

> In my current Perl prototype, the handshake goes like this:
>
>   1  sudoshell is invoked by the user.
>   2  if sudoshell isn't root, it reinvokes itself with sudo
>   3  sudoshell sends the user's name (from getpwuid or from SUDO_USER
> env) and      its pid over the main fifo to sudoscriptd.
>   4  sudoscriptd stores the username and pid and forks a child to
>      handle the session, retaining the child's pid.
>   5  the child does a setsid to disassociate from the parent
>   6  the child composes a fifo name from the username and ss pid
>   7  the child sends this name to ss using the original fifo which it
> still has open.   8  the child closes the IPC pipe and opens the data pipe
>   9  sudoshell runs script on the new pipe
>   10 the child manages the log file in the same way that the current
> sudoscriptd does.   11 the parent periodically chacks extant sessions
> (using the PIDs it has stored)      and cleans up after defunct sessions.
> (not implemented yet)
>   12 on exit, ss informs the parent sudoscriptd, who uses kill -9 to reap
> the      disaccociated child.
>
> The child sudoscriptd disassociates from the parent so that it can
> survive problems with the parent. The child is a long running daemon on
> its own, so it should have this degree of autonomy. It should also be
> possible to have the master daemon pick up old sessions started by an
> earlier sudoscriptd.
>
> The reason sudoscriptd is there in the first place is to manage
> the log file size. Since ss is scripting to a fifo, we can move the
> log aside without dropping any data, but only in a seperate process.
> In the new architecture, the per-session daemon takes on that role, while
> the master daemon takes on the new role of session traffic cop.
>
> --On Thursday, May 09, 2002 09:20:56 AM -0700 "Morris, Adam"
> <AM...@pr...> wrote:
>
>>
>> Greetings,
>>
>> 	I didn't see this thread in the archives, but I did see the new
>> architecture diagram... :-)
>>
>> I can see a couple of clarifications that I think need to be made to it,
>> and I can probably provide some code already to carry out the best part
>> of it.
>>
>> My current version doesn't generate dynamic logfile/fifo names, and it
>> doesn't have all of the error checking that it needs in it, but it's
>> getting close.
>>
>> o.k. Clarifications...
>>
>> Sudo invokes sudoshell (this is fine, but what if you're just running
>> sudoshell manually, as I run sstest... :-)
>>
>> Sudoshell opens a named pipe to sudoscriptd and announces its presence.
>>
>> Sudoscriptd should then generate a new fifo name, and pass that back to
>> sudoshell before forking.  Or Sudoshell should pass a generated fifo name
>> to sudoscriptd before it forks.
>>
>> Sudoshell then invokes script with the fifo as its output.  Suggestion...
>> if you're still going with a two process model then sudoshell should
>> fork, the parent should wait and the child can exec script.  The parent
>> will receive a SIGCHLD when the child dies and can then send a clean up
>> message to the sudoscriptd.
>>
>> I already have (as stated below) a partially complete, working, but not
>> yet usable C program that does the majority of this.  I have done away
>> with the daemon as I don't feel that I need the overhead of running it
>> all the time. Instead I have the following architecture.
>>
>> Any comments?
>>
>> Adam
>>
>> -----Original Message-----
>> From: Howard Owen [mailto:hb...@eg...]
>> Sent: Wednesday, May 08, 2002 5:36 PM
>> To: Morris, Adam
>> Subject: RE: http://www.egbok.com/music.html
>>
>>
>> Hey, cool! I've been considering a C rewrite in connection with a
>> "2.0" version that would create separate FIFOs per session. That
>> way you could track individual users which current isn't possible
>> with sudoshell. I have a sudoscriptd that forks a child when
>> contacted by sudoshell. The child creates a new FIFO based on the
>> userid and pid that sudoshell sends. It then sends the name of the
>> FIFO back to sudoshell, closes it, and opens the new one. Sudoshell
>> closes its end of the first FIFO, then runs script on the new one.
>> I was considering a C rewrite for sudoscriptd for performance reasons.
>> (Mainly reducing memory overhead of the Perl interpreter.) The advantage
>> of Perl is that it's a lot easier to do sophisticated stuff in a few
>> lines of code. I've also viewed it as a portability aid, since the
>> various Unices have varying degrees of POSIX compliance. But the
>> advantage of not needing a Perl install balance that somewhat.
>>
>> There's a sudoscript-devel mailing list at
>>    	   http://lists.sourceforge.net/lists/listinfo/sudoscript-devel
>> I'm cc'ing the list on this reply. Why don't we discuss what you are
>> doing  there,
>> then open up a CVS module at sourceforge for a C rewrite?
>>
>> --On Wednesday, May 08, 2002 03:37:01 PM -0700 "Morris, Adam"
>> <AM...@pr...> wrote:
>>>
>>> I hope that you don't mind, but I'm currently in the process of
>>> rewriting sudoshell in C.  It's not an exact rewrite, it's more of an
>>> "nice idea, but I want to..." rewrite.  My version is about half way
>>> there (it's functional but not yet useful) and still uses script.
>>>
>>> It checks that $SHELL is set to a valid shell, and then forks, the
>>> parent creates a fifo, sends a signal to the child and then logs all
>>> output from the fifo into a logfile (a separate logfile for each
>>> session).  The child waits for the signal and then runs script to the
>>> same fifo.  When the child dies the parent catches the signal, closes
>>> and removes the fifo and closes the logfile.
>>>
>>> I've got to improve the error checking a bit and add in the functions to
>>> generate the fifo name (before the fork) and the logfile name.  This
>>> should allow for per session log files.  The big advantage (for me) of a
>>> C version is that I don't need to have perl on every machine, and we
>>> don't.  As it creates its own version of the daemon that you have as a
>>> separate process it doesn't need to be running when it's not needed.
>>>
>>> So far the same source runs unmodified (and without any conditional
>>> code) on Linux and HP-UX.  I'm hoping that I'll be able to get it
>>> running on AIX and Solaris without too much (any?) modification.  Then
>>> hopefully I can persuade our security section to drop the idea of
>>> paying $30,000 plus $10,000 per annum for a commercial product that
>>> does essentially the same thing.  (It has a nicer web front end... big
>>> deal).
>>>
>>> Adam
>>>
>>
>> Howard Owen                    "Even if you are on the right
>> EGBOK Consultants               track, you'll get run over if you
>> hb...@eg...  +1-650-339-5733  just sit there." - Will Rogers
>>
>> *************************************************************************
>> *** This message is intended for the sole use of the individual and
>> entity to whom it is addressed, and may contain information that is
>> privileged, confidential and exempt from disclosure under applicable law.
>> If you are not the intended addressee, nor authorized to receive for the
>> intended addressee, you are hereby notified that you may not use, copy,
>> disclose or distribute to anyone the message or any information contained
>> in the message.  If you have received this message in error, please
>> immediately advise the sender by reply email and delete the message.
>> Thank you very much.
>>
>>
>
>
>
> Howard Owen                      "Even if you are on the right
> EGBOK Consultants                 track, you'll get run over if you
> hb...@eg...    +1-650-339-5733  just sit there." - Will Rogers
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: ban...@so...
> _______________________________________________
> Sudoscript-devel mailing list
> Sud...@li...
> https://lists.sourceforge.net/lists/listinfo/sudoscript-devel



Howard Owen                      "Even if you are on the right
EGBOK Consultants                 track, you'll get run over if you
hb...@eg...    +1-650-339-5733  just sit there." - Will Rogers
 
****************************************************************************
This message is intended for the sole use of the individual and entity to
whom it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.  If you are
not the intended addressee, nor authorized to receive for the intended
addressee, you are hereby notified that you may not use, copy, disclose or
distribute to anyone the message or any information contained in the
message.  If you have received this message in error, please immediately
advise the sender by reply email and delete the message.  Thank you very
much.