sudoscript-devel Mailing List for Sudoscript - Audited Shells (Page 2)
Brought to you by:
hbo
Menu
▾
▴
sudoscript-devel — Sudoscript Developer Discussion
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(21) |
Jun
(7) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2004 |
Jan
(3) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Howard O. <hb...@eg...> - 2002-05-28 18:39:05
|
I'm moving toward a beta release of the 2.0.0 code. I've successfully tested it on Red Hat Linux, Solaris 8 and FreeBSD 4.3. My tests on OpenBSD 3.0 have revealed some problems that may lead me to drop support for now. I'd like to include Irix in the beta, but I have no access to a system running the OS. (Weird Stuff wants a minimum of $500.00 for an Indy, the last I checked.) Could one of you SGI folks have a look at the code and give me feedback? The alpha4 release is at http://www.egbok.com/sudoscript/sudoscript-2.0.0alpha4.tar.gz Thanks. -- 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 |
|
From: Howard O. <ho...@nu...> - 2002-05-21 23:18:04
|
Howard Owen "Even if you are on the right Nuasis System Administrator track, you'll get run over if you ho...@nu... 408-350-4952 just sit there." - Will Rogers |
|
From: Howard O. <hb...@eg...> - 2002-05-21 22:49:21
|
A collegue noted that sudoscriptd was taking 80% of his CPU. It was the merger code. I neglected to (re)open the FIFO between the while(1) and while(<MYFIFO>) loops. as soon as the first session exited, the merger went into a tight loop reading past end-of-file on the FIFO. Also, rhe linux init script was not signaling the master sudoscriptd properly on shutdown. I fixed that one, but the Solaris and SGI scripts don't have the fix yet. I pushed a new dist to egbok.com. It's linked off the sudoscript home page now. Since I can't recall the freshmeat announcement, I've linked the old names to the new dist. I'll do the same when I add other fixes. Man, I much prefer finding bugs in other people's code! 8) -- 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 |
|
From: Howard O. <hb...@eg...> - 2002-05-21 21:58:09
|
I dunno how big they could get. I just know that they'll
grow significantly faster that the equivilant sudo syslogs would, since
sudoscript captures the output too. Since I could imagine cases where
both large and small amounts of data would be logged, I designed the
rotation system to check the size, and rotate on that basis. That
handles both cases nicely.
On the issue of loggers and log rotation, what the 1.0 daemon did was to
check the log size, then fork off a child to do the compression before
returning to reading the FIFO. With this model, sudoshell never knows the
rotation has taken place. It just keeps writing to the FIFO, which is
the main reason it's there.
When I considered moving to a daemon-per-session model, I thought about
the problem of rotating the individual log files. In that setup there
would be several daemons, each with their own FIFOs. They could manage
their own log files in a manner similar to the 1.0 daemon, but then noone
would be looking out for the overall log sizes. And it's open ended, 10
daemons would produce 10 times as much data, all other things being equal.
So it doesn't scale.
Thinking about a solution for this, I considered that the master daemon
could look after overall sizes. But then it would have to suspend the
individual session daemons while it started the rotator/compressors.
(This because the session daemons would be logging to the files directly,
and
would have to be told to close and reopen the log, instead of figuring it
out for
themselves as in the single-threaded case. Add complications like dead
session
daemons leaving large log files around that the master daemon would have to
deal
with and you start to worry about overall reliability.
So I finally hit on the idea of merging back into a single logging daemon
Now
the session daemons don't have to worry about logfiles, they use FIFOs for
both
input and output. The backend daemon acts very similarly to the single
threaded
1.0 daemon, so there's minimal disruption in that code. (Well, I made some
other
improvements while I was at it.) It doesn't have to lock the files or cat
/dev/null onto
them since it "owns" the log. It can just move them out of the way. The
master
daemon takes on the traffic cop role, tracking session startup and tear
down.
--On Tuesday, May 21, 2002 03:17:49 PM -0500 Tommy Smith <ts...@ea...>
wrote:
> Howard:
>
> No I haven't checked CVS lately (since a few weeks ago) I was busy
> working on these modifications yesterday afternoon.
>
> to address your points:
>
> 1) As far as monitoring size on these files, how big could they get? I
> mean, we have some processes that generate several hundred MB in a day or
> week, but it would take alot of shell activity (esp as root) to bring the
> files above a level where it would impact disk space on a system. Also, I
> want to rotate logs via cron in a systematic 'cronological' way
> (checkpointing them by an absolute date string).
>
> 2) multiple files/multiple logging daemons: how do the daemons know to lay
> off and compress now? for a time I had the 'check_sudoscriptd' fuction
> turned off for debugging - it does work per-user and just check the
> {user}-pid file when a new instance is requested but its not seeing
> itself running since the name of the daemon is hardcoded into the file
> and so it starts another D - I haven't fixed this yet. this would still
> run into the same problems with logging multiple sessions (if one was
> logged in twice or had multiple terms open, which we are apt to do often)
> to the same file and generating an out-of-sequence log without your
> session identifier tags, so I'm going to check those out. As far as
> telling the loggingD to rotate or checkpoint the file, if it can do it
> for $log it should be able to do it for any $log ?? I didn't test it
> though.
>
> so it would be rotating the logs to {logfile}-0,1,2 etc where the names
> are not unique globally ??-- I often rotate logs by way of 'cp logfile
> /backup-dir/logfile-{date}; cat /dev/null > logfile' which preserves the
> filehandle for any running processes and its only drawback is that it
> could clobber some data. (which could be a big drawback depending on the
> application, but for most, we can avoid HUPing the daemon by using this
> technique) There should be a way to 'flock' the file also & just block for
> the short time /dev/null is being cat'ed to it. Compressing logfiles is
> strictly the function of some other task on some other server (IMHO; hate
> to see a production box being under load by gzip for a big logfile,
> rather pop it over the net and compress elsewhere), I can do without that
> function and would rather have it handled externally if even neccesary.
> perhaps we could build a 'signal' into the daemon for it to
> checkpoint/rotate the logfile.
>
> 3) re: session tagging and date tagging: I am probably going to look at
> tagging the date in a
>
> YYYY:MM:DD:HH:MM format so that it will sort properly by the first field
> and be more compact
>
> 4 the end product would be to integrate these things into the ssh login
> process, so when you login to the system, it starts up a sudoscriptD for
> the account automatically & cleans up on exit or interval. having a
> signal hook on the daemon would also make it somewhat scriptable (thats
> the other reason I like multiple {user}-logfiles; the grep work is
> already done and ready for a script/browser/human to call the filename)
>
> On other fronts, I am also working on 'standardizing' the way all logfiles
> are handled across our systems and from different programs. Seems as if
> every one has a different way of rotating and archiving, if they even do
> any rotating.
>
>
> Still have not checked out your new stuff on CVS, but am going to check
> out the diagram you sent (I've printed it) -- thanks!
>
>
> the two modified codes are attached. take a look and see what you think (I
> didn't modify much, but removed most of the comments and documentation so
> I can print it out and eliminate extraneous distractions) -- perhaps
> another 'branch' to the CVS tree might be in order? in any case, I'm
> going to continue developing this for our site - I hope you find my
> modifications interesting; I appreciate your feedback and writing the
> code in the first place.
>
>
> : )
> Tommy Smith
> System Admin
> Eatel Data Network Operations.
>
>
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
|
|
From: Howard O. <hb...@eg...> - 2002-05-21 21:37:58
|
I've released 2.0.0alpha today. It's available at http://www.egbok.com/sudoscript The buffer problem is due to script(1). On Linux, you can issue a 'script -f' to get it to flush its output. That doesn't work on any of the other architectures, however. I'm seeing different behavior with my code. I get timestamps in a cluster when the buffer flushes, but not the exit time. Perhaps you are doing very short sessions? Regarding syslog, I do syslog daemon events, but not all that script(1) data. There are two reasons for this in my mind. First, script(1) output looks pretty garbled without post-processing, which could be annoying to an admin wanting to read the log for some other reason. (I know it would annoy me 8). Second, the quantity of data logged is way, way more than a typical program using syslog would produce. I handle this flood of data by turning over my log files as needed, trading of longevity of the logs for keeping log partitions free. That's a good trade-off purely in terms of sudoscript, but not necessarily for other data that could be syslogged. If syslog.conf pointed sudoscript output to /var/log/secure, for instance, then THAT file would turn over quickly, possibly flushing lots of important data that had nothing to do with sudoscript. Finally, I'd really hate to see someone use syslog to push this stuff over a network to a remote logging host. Not only would it burn bandwidth, but by-definition sensitive data would go across the wire in the clear. I'm grateful for your ideas and feedback, Tommy, but I'd really appreciate it if you subscribed to the sudoscript-devel list. Postings there are archived so that others can come up to speed, or search them for a particular topic. It's pretty low-volume, so you won't get flooded with extraneous stuff. I've CCd the list on this message. --On Tuesday, May 21, 2002 03:41:03 PM -0500 Tommy Smith <ts...@ea...> wrote: > Howard; > > just at quick glance, the date time stamps on the merge-fifo are still > going to be inacurate & just reflecting the time of buffer flush. is > there a way to have the fifos operate with a very short buffer so the > datetime stamps are more meaningful? last I checked the entire session > was coded with the datetimestamp of when 'exit' occurred , or, more > precisely, when script handed off the FIFO. seems like the structure you > have drawn is already creating session instances but just logging to the > merge fifo. some folks might say it should log to a syslog facility. > looks pretty complex though. > > .. > ? > -TS > 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 |
|
From: Howard O. <hb...@eg...> - 2002-05-21 01:00:52
|
I've branched the 1.0 code onto BRANCH_1_0. The mainline now has the 2.0 changes. You can checkout the current code with: cvs -d:pserver:ano...@cv...:/cvsroot/sudoscript login cvs -z3 -d:pserver:ano...@cv...:/cvsroot/sudoscript co sudoscript Or, you can browse the repository at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sudoscript/ 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 |
|
From: Howard O. <hb...@eg...> - 2002-05-21 00:01:18
|
I now have Perl code to implement a 2.0 architecture for sudoscript that enables multiuser operation while tagging sessions with the username and process ID. I have retained the separate sudoshell and sudoscriptd split. I looked at merging thee two based on C code posted by Adam Morris, but I couldn't get it working in Perl. (Neither the child nor the parent processes could hold on to stdin/stdout in my tests.) I also judged that it would be good to have just one log file, so as to simplify the management of the probably large quantity of data, and that requires a daemon. So attached is my diagram of the new architecture. Here's how it works. Sudoscriptd starts up and opens a front-end FIFO. It also forks a backend daemon to manage the single log file. The backend daemon creates a FIFO of its own and lurks waiting for data. When sudoshell runs, it sends a 'HELO' string to the frontend daemon over the frontend FIFO, then does a Posix::pause with a SIGHUP handler in place. (This idea is due to Adam Morris.) The frontend daemon forks a logger, which creates a session FIFO, whose name is derived from the username and PID given by sudoshell. It then sends a HUP signal to sudoshell and opens the session FIFO for read. Sudoshell wakes up and invokes script(1) onto the session FIFO, whose name it derives from its own username and PID. The logger tags all data it receives with the session ID, and logs it all to the backend FIFO. The backend sudoscriptd merges the data onto a log file after date-stamping it. It also checks the log file size every 30 seconds, rotating and compressing it as needed. All the daemons now use sys to report their progress. All have signal handlers to gracefully shut down. The frontend sudoscriptd tracks all extant processes. When sudoshell exits, it tells the frontend daemon so, which shuts down the associated logger. This architecture is considerably more complicated than the 1.0 code. I think there are definite benefits for the added complexity. Mainly it allows tracking of individual sessions, while retaining the benefits of a single log file. Nevertheless, I'm going to test it much more extensively on the architectures I have access to. After that, I'll do a beta release and gather feedback from the adventurous, before doing a final release. I'll branch the repository sometime today and commit the new code. I'll announce its availability here when I'm done. -- 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 |
|
From: Howard O. <hb...@eg...> - 2002-05-10 01:39:06
|
You could put something like sudoshell in the shell field of /etc/passwd. I wouldn't recommend it, though. Depending on how many users your system had, you'd end up logging a huge amount of data. Since there's no relable and easy way to seperate user input from command output, you'd be saving a potentially large quantity of information for every command invocation. Sudoscriptd manages the amount of information logged, throwing away old logs as new ones get written. This is the only advantage sudoscript would have over a simple shell wrapper for the application you want. Of course, you will still be throwing everyone's log data into the same file in the end, making it even harder to make sense of the output. I'm working on a 2.0 design that will fix that particular problem. Two things would have to change in sudoshell/sudoscriptd in order to allow logging by ordinary users. First, the root check in sudoshell would have to be removed. Second, the permissions on /var/run/sudoscriptd would have to be opened up so that ordinary users could write to the typescript. Since there's just one typescript, this means that anyone could mess with your sudoscript logs. All in all, I don't think that sudoscript is suitable for what you want. --On Thursday, May 09, 2002 06:13:51 PM -0700 Florin Andrei <fl...@sg...> wrote: > Maybe i'm asking the wrong question, but anyway... > > Currently, you have to run sudoshell via sudo to get the audited shell. > But, honestly, i'm not happy with that. I want an audited shell right > from the beginning, not just after the user ran sudo. > > I wonder if it's possible to modify sudoshell so that it can be declared > the user's default shell; so, when the user logs into the system, it > gets the audited shell from the first moment. > I'm not sure if that's possible with the current architecture. But i > would like to have a toy like that. ;-) > > -- > Florin Andrei > > There's nothing to be ashamed of in coming up with the obvious, > especially when nobody else is coming up with it. > > > _______________________________________________________________ > > 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 |
|
From: Florin A. <fl...@sg...> - 2002-05-10 01:14:22
|
Maybe i'm asking the wrong question, but anyway... Currently, you have to run sudoshell via sudo to get the audited shell. But, honestly, i'm not happy with that. I want an audited shell right from the beginning, not just after the user ran sudo. I wonder if it's possible to modify sudoshell so that it can be declared the user's default shell; so, when the user logs into the system, it gets the audited shell from the first moment. I'm not sure if that's possible with the current architecture. But i would like to have a toy like that. ;-) -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. |
|
From: Howard O. <hb...@eg...> - 2002-05-10 00:51:42
|
From where I sit, our goals are convergent over most of the development. I understand where you are going with this, and I don't want to tie you down to my project, but I think we might each be able to get some leverage with each other's code. To be perfectly honest, I'd like a peek at what you are doing so I can compare it to what I'm doing, and maybe steal some good ideas. 8) (Open source is something like folk music in that regard 8) Specifically, I want to rewrite sudoscriptd in C, not so I can ditch Perl, but so I can improve the performance of the daemon. You say you are doing sudoscriptd-like stuff in the single executable. I'm researching the possibility of having just one executable based on your idea. We both seem to have independently arrived at the notion of logging per-session. There's enough congruence that I'd like to get a look at what you are doing. I just had 22 Dell PowerEdge 1650s land on my desk. (Ouch!) so I may not be very responsive over the next week or so. --On Thursday, May 09, 2002 02:48:23 PM -0700 "Morris, Adam" <AM...@pr...> wrote: > 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. > 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 |
|
From: Morris, A. <AM...@pr...> - 2002-05-09 21:48:24
|
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. |
|
From: Howard O. <hb...@eg...> - 2002-05-09 18:37:17
|
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 |
|
From: Howard O. <hb...@eg...> - 2002-05-09 17:32:52
|
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
|
|
From: Morris, A. <AM...@pr...> - 2002-05-09 16:20:57
|
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. |
|
From: Howard O. <hb...@eg...> - 2002-05-09 05:52:55
|
Tommy Smith from Eatel suggested that I consider running a log-per-session with sudoscript. This struck me as a very good idea for several reasons. First and foremost, it provides a way to uniqely identify a particular session's output. Rather than multiplaxing all sessions through a single typescript FIFO, we could provide a FIFO per session, and thus a log per session. A second benefit is that the master sudscriptd could provide traffic cop functions, cleaning up after defunct sessions. Finally, the master daemon could use syslog to track session startup and shutdown. (I've been reluctant to use syslog so far because of the huge quantity of data that can be produced.) I've drawn up an architecture to implement these ideas. It's available at http://www.egbok.com/sudoscript/new_arch.gif. I have 90% of an implementation done in Perl, too. One thing I want to consider is a rewrite of sudiscriptd in C. I'm concerned that the overhead associated with the Perl interpreter will start to get significant when more than a few users are active on a single system. Comments and suggestions are very welcome! 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 |
|
From: Howard O. <how...@nu...> - 2002-05-03 01:36:35
|
Thanks for everyone's help. It should be showing up on Freshmeat soon. |
|
From: Howard O. <how...@nu...> - 2002-05-02 20:53:42
|
Thanks, Chan! I'd already decided to go with /usr/local on Irix to avoid colliding with anything you guys might do. I'm ready to tag and release, but I thought I'd give you (and anyone else on the list) a chance to look over the dist before I do. I'll do the deed at around 6:00 PM PST if I don't hear of any show-stoppers. The candidate tarball is at http://www.egbok.com/sudoscript/sudoscript-1.0.4.tar.gz Thanks again! > -----Original Message----- > From: Chan Wilson [mailto:cw...@sl...] > Sent: Wednesday, May 01, 2002 5:03 PM > To: Howard Owen > Cc: sud...@li... > Subject: Re: [Sudoscript-devel] Update to INSTALL file needed > > > See attached. > > --Chan > > On 0, Howard Owen <ho...@nu...> inscribed onto the > electric medium... > > Thanks for your diffs, Chan. I've hacked the Makefile, but > I need an update > > to > > the INSTALL document for Irix. If you'd like to write it, > that would be > > great > > but if not, could you send me the information to accomplish > the task? I've > > attached the current INSTALL file to this email. > > > > Thanks again, > > > > Howard Owen "Even if you are on the right > > Nuasis System Administrator track, you'll get run > over if you > > ho...@nu... 408-350-4952 just sit there." - Will Rogers > > > -- > > Chan Wilson :: cw...@sg... :: 650/933-9515 :: SGI > Enterprise Net Services > > People don't ask for facts in making up their minds. They > would rather have > one good soul-satisfying emotion than a dozen facts. > --Leavitt > > |
|
From: Chan W. <cw...@sl...> - 2002-05-02 00:03:20
|
See attached. --Chan On 0, Howard Owen <ho...@nu...> inscribed onto the electric medium... > Thanks for your diffs, Chan. I've hacked the Makefile, but I need an update > to > the INSTALL document for Irix. If you'd like to write it, that would be > great > but if not, could you send me the information to accomplish the task? I've > attached the current INSTALL file to this email. > > Thanks again, > > Howard Owen "Even if you are on the right > Nuasis System Administrator track, you'll get run over if you > ho...@nu... 408-350-4952 just sit there." - Will Rogers -- Chan Wilson :: cw...@sg... :: 650/933-9515 :: SGI Enterprise Net Services People don't ask for facts in making up their minds. They would rather have one good soul-satisfying emotion than a dozen facts. --Leavitt |
|
From: Chan W. <cw...@sl...> - 2002-05-02 00:02:52
|
niglet: perltidy isn't in CVS. install niglet: if effective uid is 0 (eg, root already) don't invoke sudo to install? plz install Irix stuff just into /usr/local vs /usr/freeware, as /usr/freeware has been unofficially reserved for "SGI Packaged Freeware." I believe 'alien' will translate .rpm to SGI inst style, although I haven't used it myself... --Chan On 0, Howard Owen <ho...@nu...> inscribed onto the electric medium... > I've also committed my changes leading toward a new release. > The Makefile needs testing on a real live Irix system. I'll tag > and release as soon as we have the testing done. (I have to test > the other architectures as well.) and after Chan and I discuss > the final form of his mods. > > Hope freshmeat doesn't tell me to go away. Release early, release > often. 8) > > CVS info is at http://sourceforge.net/cvs/?group_id=50616 > > -- > Howard Owen "Even if you are on the right > Nuasis System Administrator track, you'll get run over if you > ho...@nu... 408-350-4952 just sit there." - Will Rogers > > _______________________________________________ > Sudoscript-devel mailing list > Sud...@li... > https://lists.sourceforge.net/lists/listinfo/sudoscript-devel -- Chan Wilson :: cw...@sg... :: 650/933-9515 :: SGI Enterprise Net Services People don't ask for facts in making up their minds. They would rather have one good soul-satisfying emotion than a dozen facts. --Leavitt |
|
From: Howard O. <hb...@eg...> - 2002-04-25 20:56:06
|
I think this idea is dead. Here's some log output from a later version of
the
code I posted:
Apr 25 13:41:29 howen02 sudo: howen : TTY=pts/7 ;
PWD=/home/howen/sandbox/script ; USER=root ; COMMAND=./script
Apr 25 13:41:32 howen02 sudoshell[1263]: howen: ^[OA^[OA^[OB^M
Apr 25 13:41:35 howen02 sudoshell[1263]: howen: ^[OA^[OA^M
I hit 'up-arrow, up-arrow, enter'. Naturally, the shell is the guy that
interprets
the tabs and such. script(1) just sees the keyboard input. The doshell()
part
of script just execl's the shell with the proper I/O handles. You could
intercept the
output, but then you have to decide what is input and what is output, which
you might
as well do from Perl. I earlier considered this to be impossible to do in a
general way,
as you cannot rely on PS1 to be set to anything in particular, since it's
settable by the
user. Hence you can't know for sure what the command prompt looks like.
The consequence of missing the prompt would be loss of audit trail, which I
judge
to be unacceptable for something like sudoscript.
It does seem possible to tag activity with a username by hacking on
script(1). I'm
just not sure the considerable effort of maintaining a script(1) fork is
worth this
marginal benefit.
--On Thursday, April 25, 2002 12:28:18 PM -0700 Howard Owen
<ho...@nu...> wrote:
> Well, I have proof-of-concept code for a mod to doinput() in the linux
> script(1) source. I haven't rigerously analyzed it for buffer offset goofs
> or anything else for that matter. But I've compiled it and watched my
> commands show up in /var/log/secure as I expected. Here's the code:
>
> doinput() {
> register int cc;
> char ibuf[BUFSIZ];
> char logbuf[LOGBUFSIZ];
> char *lbptr;
> register int lc;
> int line_flag;
> lc=-1;
> (void) fclose(fscript);
> (void) openlog( "sudoshell", LOG_PID, LOG_AUTHPRIV);
>
> while ((cc = read(0, ibuf, BUFSIZ)) > 0) {
> (void) write(master, ibuf, cc);
> if (lc+cc >(LOGBUFSIZ-2)){
> logbuf[lc]=0;
> lc=-1;
> (void) syslog(LOG_INFO,"%s",logbuf);
> }
> if (ibuf[cc-1]==13) {
> line_flag=1;
> } else {
> line_flag=0;
> }
> ibuf[cc]=0;
> lbptr=&logbuf[lc+1];
> strncpy(lbptr,ibuf,cc);
> lc+=cc;
> if (line_flag){
> logbuf[lc]=0;
> (void) syslog(LOG_INFO,"%s",logbuf);
> lc=-1;
> }
> }
> done();
> }
>
> Howard Owen "Even if you are on the right
> Nuasis System Administrator track, you'll get run over if you
> ho...@nu... 408-350-4952 just sit there." - Will Rogers
>
> _______________________________________________
> 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
|
|
From: Howard O. <ho...@nu...> - 2002-04-25 19:29:17
|
Well, I have proof-of-concept code for a mod to doinput() in the linux
script(1) source. I haven't rigerously analyzed it for buffer offset goofs
or anything else for that matter. But I've compiled it and watched my
commands
show up in /var/log/secure as I expected. Here's the code:
doinput() {
register int cc;
char ibuf[BUFSIZ];
char logbuf[LOGBUFSIZ];
char *lbptr;
register int lc;
int line_flag;
lc=-1;
(void) fclose(fscript);
(void) openlog( "sudoshell", LOG_PID, LOG_AUTHPRIV);
while ((cc = read(0, ibuf, BUFSIZ)) > 0) {
(void) write(master, ibuf, cc);
if (lc+cc >(LOGBUFSIZ-2)){
logbuf[lc]=0;
lc=-1;
(void) syslog(LOG_INFO,"%s",logbuf);
}
if (ibuf[cc-1]==13) {
line_flag=1;
} else {
line_flag=0;
}
ibuf[cc]=0;
lbptr=&logbuf[lc+1];
strncpy(lbptr,ibuf,cc);
lc+=cc;
if (line_flag){
logbuf[lc]=0;
(void) syslog(LOG_INFO,"%s",logbuf);
lc=-1;
}
}
done();
}
Howard Owen "Even if you are on the right
Nuasis System Administrator track, you'll get run over if you
ho...@nu... 408-350-4952 just sit there." - Will Rogers
|
|
From: Howard O. <hb...@eg...> - 2002-04-25 17:46:01
|
In theory, yes. But the list didn't exist when the discussion started. 8) ---------- Forwarded Message ---------- Date: Thursday, April 25, 2002 10:34:52 AM -0700 From: Florin Andrei <fl...@sg...> To: Howard Owen <hb...@eg...> Subject: Re: sudoshell I don't mind at all. The whole discussion should have started on the mailing list anyway. I just subscribed to the mailing list. On Thu, 2002-04-25 at 10:30, Howard Owen wrote: > Do you mind if I forward this to sudoscript-devel, Florin? You can > subscribe, if you care to, at > http://lists.sourceforge.net/mailman/listinfo/sudoscript-devel > > --On Thursday, April 25, 2002 10:23:25 AM -0700 Florin Andrei > <fl...@sg...> wrote: > > > Yeah, that's fine. Even inside the Linux world, there are many init > > scripts "styles" with different distributions. That will change once the > > Linux standards will become more prominent, but until then... > >> From what i see, people simply choose to provide different init scripts > > for different OSs/distributions. > > > > On Wed, 2002-04-24 at 16:20, Howard Owen wrote: > >> I'm not sure its going to be possible to make a single init script for > >> Linux, Solaris > >> and Irix. The Solaris case is just too different. Irix and Red Hat > >> Linux both use a > >> 'chkconfig' system. The Red Hat chkconfig uses the comments in the init > >> files to determine > >> the runlevels, which are exercised by 'chkconfig on' and 'chkconfig > >> off', Your > >> code has a 'links' case for doing that. My Irix experience is about > >> four years out of date > >> and I don't recall how chkconfig is implemented, exactly. Is the > >> 'links' case the standard > >> mechanism for adding the links with 'chkconfig on'? What does > >> 'chkconfig off' rely on? > >> Also, I'd prefer using some more explicit test of the platform rather > >> than testing for the > >> existence of '/etc/rc.d'. I assume that your 'uname -s' returns 'irix'? > >> > >> In case we decide to use a seperate o > >> ir > >> --On Wednesday, April 24, 2002 12:18:01 PM -0700 Chan Wilson > >> <cw...@co...> wrote: > >> > >> > Hi Howard, > >> > > >> > Attached you'll find a patch which fixes several perl issues WRT > >> > precedence (mainly, saying "open blah, foo || die" won't ever > >> > actually die) and a few other nigglets that caught my eye while > >> > getting this to work under Irix. I've also included an init script > >> > for Irix which comes from a generic template; you may want to adjust > >> > / add to it so you only need one flavor of init script. > >> > > >> > I may have some more after I try this out a bit; I've been looking > >> > for something like this for awhile and although it's got > >> > shortcomings its a tactic to play with... > >> > > >> > thanks, > >> > > >> > --Chan > >> > > >> > Chan Wilson :: cw...@sg... :: 650/933-9515 :: SGI Enterprise Net > >> > Services > >> > > >> > People don't ask for facts in making up their minds. They would > >> > rather have one good soul-satisfying emotion than a dozen facts. > >> > --Leavitt > >> > > >> > > >> > >> > >> > >> 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 > > -- > > Florin Andrei > > > > There's nothing to be ashamed of in coming up with the obvious, > > especially when nobody else is coming up with it. > > > > > > 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 -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. ---------- End Forwarded Message ---------- 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 |
|
From: Howard O. <hb...@eg...> - 2002-04-25 07:08:14
|
I got a sugestion from Carl for a modification to sudoscript so
that it would only log commands typed by the user, so what you
would see in the log would be closer to what is there when a user
types sudo before everything. (Good user! Good!) I commented at the
time that the only way I could see to do this reliably would be to
modify script(1) to do the logging, since it's the only one that jnows
for sure what is input and what is output. I have since had a look
at the Red Hat source for script (from util-linux-2.11f) and it looks
like it would be fairly easy to do. What script does is fork twice to
create three processes:
(void) signal(SIGCHLD, finish);
child = fork();
if (child < 0) {
perror("fork");
fail();
}
if (child == 0) {
subchild = child = fork();
if (child < 0) {
perror("fork");
fail();
}
if (child)
dooutput();
else
doshell();
} else
(void) signal(SIGWINCH, resize);
doinput();
return 0;
One child execs the shell, and one does the output to the typescript.
The parent does the input side, which is what we'd be interested in.
It looks like it would be trivial to hook in calls to syslog in the
input loop:
void
doinput() {
register int cc;
char ibuf[BUFSIZ];
(void) fclose(fscript);
while ((cc = read(0, ibuf, BUFSIZ)) > 0)
(void) write(master, ibuf, cc);
done();
}
We could also tag the log output with the user's name, obtained by
a getpwuid at startup. I have several worries about how to integrate
something like this into sudoscript:
o portability
The Linux version appears to be based on BSD source, probably from
4.4BSDlite. This means porting to the *BSDs should be easy. However,
script uses ptys, which are different or non-existent on SysV derived
unices.I don't know if there are any freely available sysV sources
out there, so we might have to reinvent the wheel.
o complication
Even though sudoscript doesn't hand out any privileges, relying on sudo
for
that, this is still security software, so keeping it simple is a great
virtue.
Maintaining a fork of script would complicate things.
I think we'd still want to offer the current style of logging, since
script(1)
logs are a known (if not loved) quantity in the community.
Any thoughts?
(Carl, if you want, you can subscribe to sudoscript-devel by going to
http://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
|
|
From: Howard O. <ho...@nu...> - 2002-04-25 02:10:11
|
I've also committed my changes leading toward a new release. The Makefile needs testing on a real live Irix system. I'll tag and release as soon as we have the testing done. (I have to test the other architectures as well.) and after Chan and I discuss the final form of his mods. Hope freshmeat doesn't tell me to go away. Release early, release often. 8) CVS info is at http://sourceforge.net/cvs/?group_id=50616 -- Howard Owen "Even if you are on the right Nuasis System Administrator track, you'll get run over if you ho...@nu... 408-350-4952 just sit there." - Will Rogers |
|
From: Howard O. <ho...@nu...> - 2002-04-25 01:33:42
|
Thanks for your diffs, Chan. I've hacked the Makefile, but I need an update to the INSTALL document for Irix. If you'd like to write it, that would be great but if not, could you send me the information to accomplish the task? I've attached the current INSTALL file to this email. Thanks again, Howard Owen "Even if you are on the right Nuasis System Administrator track, you'll get run over if you ho...@nu... 408-350-4952 just sit there." - Will Rogers |
2341 messages has been excluded from this view by a project administrator.
