From owner-freebsd-audit Sun Oct 27 0:50:56 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D873737B401; Sun, 27 Oct 2002 00:50:52 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7CDE43E3B; Sun, 27 Oct 2002 00:50:50 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226]) by baraca.united.net.ua (8.12.6/8.11.6) with ESMTP id g9R7oih4090317; Sun, 27 Oct 2002 09:50:46 +0200 (EET) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.6/8.12.5) with ESMTP id g9R7onaJ036558; Sun, 27 Oct 2002 09:50:49 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.6/8.12.5/Submit) id g9R7ohAE036557; Sun, 27 Oct 2002 09:50:43 +0200 (EET) Date: Sun, 27 Oct 2002 09:50:43 +0200 From: Maxim Sobolev To: Nate Lawson Cc: jlemon@FreeBSD.ORG, hackers@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC Message-ID: <20021027075043.GA36533@vega.vega.com> References: <3DB79DFA.FA719B8F@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote: > On Thu, 24 Oct 2002, Maxim Sobolev wrote: > > Please review the patch, which adds two new types of events - > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get > > notification when the image starts or stops executing. For example, it > > could be used to monitor that a daemon is up and running and notify > > administrator when for some reason in exits. I am running this code > > for more than a year now without any problems. > > > > Any comments and suggestions are welcome. > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you > want to write your own, couldn't you use waitpid()? Or a kevent() of > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for > this. EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on vnodes - it is the main difference. Currently, you can't reliably get a notification when kernes started executing some arbitrary executable from your fs. > Comments below. > > > +.It NOTE_STOPEXEC > > +Execution of the file referenced by the descriptor ended. Triggered > > when > > +the process associated with the file exited or was replaced with anoter > > +image using > > +.Xr execve 2 > > +or simial syscall. The PID of the process is returned in > ^^^^^ > typo OK, fixed. > > Index: src/sys/sys/event.h > > =================================================================== > > RCS file: /home/ncvs/src/sys/sys/event.h,v > > retrieving revision 1.21 > > diff -d -u -r1.21 event.h > > --- src/sys/sys/event.h 29 Jun 2002 19:14:52 -0000 1.21 > > +++ src/sys/sys/event.h 24 Oct 2002 06:57:41 -0000 > > @@ -83,13 +83,15 @@ > > /* > > * data/hint flags for EVFILT_VNODE, shared with userspace > > */ > > -#define NOTE_DELETE 0x0001 /* vnode was removed */ > > -#define NOTE_WRITE 0x0002 /* data contents changed */ > > -#define NOTE_EXTEND 0x0004 /* size increased */ > > -#define NOTE_ATTRIB 0x0008 /* attributes changed */ > > -#define NOTE_LINK 0x0010 /* link count changed */ > > -#define NOTE_RENAME 0x0020 /* vnode was renamed */ > > -#define NOTE_REVOKE 0x0040 /* vnode access was revoked */ > > +#define NOTE_DELETE 0x00100000 /* vnode was removed */ > > +#define NOTE_WRITE 0x00200000 /* data contents changed */ > > +#define NOTE_EXTEND 0x00400000 /* size increased */ > > +#define NOTE_ATTRIB 0x00800000 /* attributes changed */ > > +#define NOTE_LINK 0x01000000 /* link count changed */ > > +#define NOTE_RENAME 0x02000000 /* vnode was renamed */ > > +#define NOTE_REVOKE 0x04000000 /* vnode access was revoked */ > > +#define NOTE_STARTEXEC 0x08000000 /* vnode was executed */ > > +#define NOTE_STOPEXEC 0x10000000 /* vnode execution stopped */ > > +/* Applies both to EVFILT_VNODE and EVFILT_PROC */ > > #define NOTE_PDATAMASK 0x000fffff /* mask for pid */ > > I don't think we should burn our 32 bits on this. Since pids are 32 bits, > this interface will fail unpredictably. This is no different from the current situation and doesn't add any new breakage. All EVFILT_PROC are currently limited to 16-bit pids only. Of course this misbehaviour should be fixed eventually, but it wasn't the purpose of this patch. > > /* additional flags for EVFILT_PROC */ > > Index: src/sys/kern/kern_exec.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v > > retrieving revision 1.193 > > diff -d -u -r1.193 kern_exec.c > > --- src/sys/kern/kern_exec.c 11 Oct 2002 21:04:01 -0000 1.193 > > +++ src/sys/kern/kern_exec.c 24 Oct 2002 06:57:41 -0000 > > @@ -518,6 +518,8 @@ > > * to locking the proc lock. > > */ > > textvp = p->p_textvp; > > + if (textvp) > > + VN_KNOTE(textvp, NOTE_STOPEXEC | p->p_pid); > > p->p_textvp = ndp->ni_vp; > > Do these always stay an int or are there casts that could result in endian > problems? > > >Index: src/sys/kern/kern_fork.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v > >retrieving revision 1.172 > >diff -d -u -r1.172 kern_fork.c > >--- src/sys/kern/kern_fork.c 18 Oct 2002 17:45:41 -0000 1.172 > >+++ src/sys/kern/kern_fork.c 24 Oct 2002 06:58:03 -0000 > >@@ -724,6 +724,8 @@ > > * tell any interested parties about the new process > > */ > > KNOTE(&p1->p_klist, NOTE_FORK | p2->p_pid); > >+ if (p2->p_textvp != NULL) > >+ VN_KNOTE(p2->p_textvp, NOTE_STARTEXEC | p2->p_pid); > > PROC_UNLOCK(p1); > > > > /* > > This shows my doubt for the need for this since the NOTE_FORK is immediately > before your duplicate NOTE_STARTEXEC. Again, they apply to a different types of objects - NOTE_FORK is for pids, while NOTE_STARTEXEC is for vnodes. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 27 1: 4:30 2002 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 2AAB037B401; Sun, 27 Oct 2002 01:04:29 -0700 (PDT) Date: Sun, 27 Oct 2002 01:04:29 -0700 From: Juli Mallett To: Maxim Sobolev Cc: Nate Lawson , jlemon@FreeBSD.ORG, hackers@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC Message-ID: <20021027010429.A90908@FreeBSD.org> References: <3DB79DFA.FA719B8F@FreeBSD.org> <20021027075043.GA36533@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021027075043.GA36533@vega.vega.com>; from sobomax@FreeBSD.ORG on Sun, Oct 27, 2002 at 09:50:43AM +0200 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Maxim Sobolev [ Data: 2002-10-27 ] [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ] > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote: > > On Thu, 24 Oct 2002, Maxim Sobolev wrote: > > > Please review the patch, which adds two new types of events - > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get > > > notification when the image starts or stops executing. For example, it > > > could be used to monitor that a daemon is up and running and notify > > > administrator when for some reason in exits. I am running this code > > > for more than a year now without any problems. > > > > > > Any comments and suggestions are welcome. > > > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you > > want to write your own, couldn't you use waitpid()? Or a kevent() of > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for > > this. > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on > vnodes - it is the main difference. Currently, you can't reliably > get a notification when kernes started executing some arbitrary > executable from your fs. This is not a job for the kernel, I don't think. Implement it in userland in terms of having the daemon write to a pidfile at startup, and have SIGUSR1 make it tell the sender it's alive (using my sigq stuff this is trivial, just send SIGUSR2 back), and periodically read the pidfile and try to communciate with the daemon, and respawn it if it fails. This could be racey if done poorly. However if you want this for *any* executable, rather than just "some arbitrary executable" rather than some specific job, then while I wonder how useful it is in a generic concept, the kq solution might be more reasonable. Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 27 1:23: 9 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54E0437B401; Sun, 27 Oct 2002 01:23:08 -0700 (PDT) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FE1F43E3B; Sun, 27 Oct 2002 01:23:07 -0700 (PDT) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226]) by baraca.united.net.ua (8.12.6/8.11.6) with ESMTP id g9R8N4h4091536; Sun, 27 Oct 2002 10:23:05 +0200 (EET) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.6/8.12.5) with ESMTP id g9R8NAaJ036678; Sun, 27 Oct 2002 10:23:10 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.6/8.12.5/Submit) id g9R8N9JJ036677; Sun, 27 Oct 2002 10:23:09 +0200 (EET) Date: Sun, 27 Oct 2002 10:23:09 +0200 From: Maxim Sobolev To: Juli Mallett Cc: Nate Lawson , jlemon@FreeBSD.ORG, hackers@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC Message-ID: <20021027082309.GC36533@vega.vega.com> References: <3DB79DFA.FA719B8F@FreeBSD.org> <20021027075043.GA36533@vega.vega.com> <20021027010429.A90908@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20021027010429.A90908@FreeBSD.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote: > * De: Maxim Sobolev [ Data: 2002-10-27 ] > [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ] > > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote: > > > On Thu, 24 Oct 2002, Maxim Sobolev wrote: > > > > Please review the patch, which adds two new types of events - > > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get > > > > notification when the image starts or stops executing. For example, it > > > > could be used to monitor that a daemon is up and running and notify > > > > administrator when for some reason in exits. I am running this code > > > > for more than a year now without any problems. > > > > > > > > Any comments and suggestions are welcome. > > > > > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you > > > want to write your own, couldn't you use waitpid()? Or a kevent() of > > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for > > > this. > > > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on > > vnodes - it is the main difference. Currently, you can't reliably > > get a notification when kernes started executing some arbitrary > > executable from your fs. > > This is not a job for the kernel, I don't think. Why not? Kernel now reports number of internal events via kqueue(2) interface, there is nothing wrong in adding yet another one. BTW, linux and irix already have similar functionality provided by /dev/imon. > Implement it in userland > in terms of having the daemon write to a pidfile at startup, and have SIGUSR1 > make it tell the sender it's alive (using my sigq stuff this is trivial, just > send SIGUSR2 back), and periodically read the pidfile and try to communciate > with the daemon, and respawn it if it fails. This could be racey if done > poorly. However if you want this for *any* executable, rather than just > "some arbitrary executable" rather than some specific job, then while I wonder > how useful it is in a generic concept, the kq solution might be more > reasonable. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 27 1:24:20 2002 Delivered-To: freebsd-audit@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 5D90C37B401; Sun, 27 Oct 2002 01:24:19 -0700 (PDT) Date: Sun, 27 Oct 2002 01:24:19 -0700 From: Juli Mallett To: Maxim Sobolev Cc: Nate Lawson , jlemon@FreeBSD.ORG, hackers@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC Message-ID: <20021027012419.A94775@FreeBSD.org> References: <3DB79DFA.FA719B8F@FreeBSD.org> <20021027075043.GA36533@vega.vega.com> <20021027010429.A90908@FreeBSD.org> <20021027082309.GC36533@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021027082309.GC36533@vega.vega.com>; from sobomax@FreeBSD.ORG on Sun, Oct 27, 2002 at 10:23:09AM +0200 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Maxim Sobolev [ Data: 2002-10-27 ] [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ] > On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote: > > * De: Maxim Sobolev [ Data: 2002-10-27 ] > > [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ] > > > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote: > > > > On Thu, 24 Oct 2002, Maxim Sobolev wrote: > > > > > Please review the patch, which adds two new types of events - > > > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get > > > > > notification when the image starts or stops executing. For example, it > > > > > could be used to monitor that a daemon is up and running and notify > > > > > administrator when for some reason in exits. I am running this code > > > > > for more than a year now without any problems. > > > > > > > > > > Any comments and suggestions are welcome. > > > > > > > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you > > > > want to write your own, couldn't you use waitpid()? Or a kevent() of > > > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for > > > > this. > > > > > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on > > > vnodes - it is the main difference. Currently, you can't reliably > > > get a notification when kernes started executing some arbitrary > > > executable from your fs. > > > > This is not a job for the kernel, I don't think. > > Why not? Kernel now reports number of internal events via kqueue(2) interface, > there is nothing wrong in adding yet another one. BTW, linux and irix already > have similar functionality provided by /dev/imon. If you implemented a kq interface, and an imon wrapper, I'd be much more impressed. A less-divergant interface to do this would be nice, even if kq is the backing. In fact, especially if kq is the backing, kq is strong, kq will make us smart. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 27 1:51:47 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 196A037B401; Sun, 27 Oct 2002 01:51:44 -0800 (PST) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD8F43E65; Sun, 27 Oct 2002 01:51:38 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0011.cvx40-bradley.dialup.earthlink.net ([216.244.42.11] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 185k50-00044x-00; Sun, 27 Oct 2002 01:51:34 -0800 Message-ID: <3DBBB6D9.F369A5CD@mindspring.com> Date: Sun, 27 Oct 2002 01:50:17 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Juli Mallett Cc: Maxim Sobolev , Nate Lawson , jlemon@FreeBSD.ORG, hackers@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC References: <3DB79DFA.FA719B8F@FreeBSD.org> <20021027075043.GA36533@vega.vega.com> <20021027010429.A90908@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Juli Mallett wrote: > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on > > vnodes - it is the main difference. Currently, you can't reliably > > get a notification when kernes started executing some arbitrary > > executable from your fs. > > This is not a job for the kernel, I don't think. Implement it in userland > in terms of having the daemon write to a pidfile at startup, and have SIGUSR1 > make it tell the sender it's alive (using my sigq stuff this is trivial, just > send SIGUSR2 back), and periodically read the pidfile and try to communciate > with the daemon, and respawn it if it fails. This could be racey if done > poorly. However if you want this for *any* executable, rather than just > "some arbitrary executable" rather than some specific job, then while I wonder > how useful it is in a generic concept, the kq solution might be more > reasonable. The problem with daemon's is that they are not children of a process other than "init". It's only useful to use SIGCHLD as the termination notification if it's a parent process being notified. For most daemons, this would mean relacing "init". It's useful to replace "init", and "syslog", both, to be able to track state for services; however, the notification on termination is significantly better if anyone who cares can monitor for it. The main problem with this approach is that it's not the service identity that's communicated, but the name of a file, and the file name is for a path that's probably relative to the current directory in most cases (or could be), and so isn't globally unique. It is also not useful to poll, since your daemon could be down for an entire poll interval; also, it means you have to trust the poll interval itself will be maintained... and if your failure is a failure of the process doing the polling itself, that's broken. In terms of most services, actually gross notification is the minmal level of assurance: just because a program that's supposed to offer a service is caught in an endless loop, so that there has not been an exit, doesn't mean that it's actually offering the service that it was intended to offer. The best check is to actually attach to, and utilize the service. There is also an intermediate level... which is probably best served by kevents, actually. For network services, when a listen on a socket occurs, it occurs on a socket specific to a service: a well known port. One obvious thing to do is to cause events to occur when a listen is issued, and when a listen socket is closed. One might also do an implicit listen in the case of an outstanding listen socket, for which no listen was executed (default listen queue depth)... basically a blocking accept vs. a connect and/or a select for readability on an outstanding socket. So there are various levels of service availability notification: 0) A "ping" of the system offering the service indicates that the interrupt code and network stack are active, but nothing else. 1) The program is running/stopped, with a notification latency (this is your suggested scenario, having to do with pid files). 2) The program is running/stopped, with no notification latency (this is the NOTE_STARTEXEC/NOTE_STOPEXEC scenario). 3) A server is listening on a well known port/has stopped listening on a well known port (this is my suggested scenario, and has the benefit of accounting for configuration and other latencies that #1 and #2 can miss -- it closes race windows). 4) Active status monitoring, through attempts to actually use a service offered by a server (e.g. making a DNS request to a DNS server, doing a "HEAD /" on an HTTP server, saying "EHLO" to an SMTP server, etc.). Obviously, #4 is the best approach. Barring that, #3 provides much better identification of services, but onl works on netwqork services. #2 provides information about services by (potentially relative or non-matching) path name. Actually, the best approach for this would be to return a "stat" buffer for the file that was exec'ed or stopped, so that the caller could use the name information for logging, but could verify that the "sendmail" being run was, say, /usr/local/bin/sendmail, instead of /usr/sbin/sendmail: the way this would work is to have the program which cared stat the executable that it expected to run, and then compare the "stat" information (dev_t and ino_t) to verify that the uniquely identified executable was in fact what was running. This is *much* better than a (partial) path comparison by (nonunique) file name (consider also: hard links with different names). So, in general: o NOTE_STARTEXEC/NOTE_STOPEXEC are a good idea; they close a latency window, and they close a race window, and the eliminate a single-point-of-failure that would come from having one monitoring program ("who monitors the monitors?"). o The name information being returned is insufficient to uniquely identify the executable to an interested program o Minimally, the information the interested program really wants is the dev_t/ino_t pair o It's OK to offer the exec path name information, at least as much of it as is known, but that's additional information, and is not sufficient for the application for which the interface was intended. At best, it may be useful for logging purposes o Another event set for NOTE_STARTLISTEN/NOTE_STOPLISTEN would be significantly more useful for most purposes for which the NOTE_STARTEXEC/NOTE_STOPEXEC events are being introduced -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 27 1:58:11 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05BE537B401; Sun, 27 Oct 2002 01:58:10 -0800 (PST) Received: from baraca.united.net.ua (ns.united.net.ua [193.111.8.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E58D43E42; Sun, 27 Oct 2002 01:58:08 -0800 (PST) (envelope-from max@vega.com) Received: from vega.vega.com (xDSL-2-2.united.net.ua [193.111.9.226]) by baraca.united.net.ua (8.12.6/8.11.6) with ESMTP id g9R9w5h4095172; Sun, 27 Oct 2002 11:58:06 +0200 (EET) (envelope-from max@vega.com) Received: from vega.vega.com (max@localhost [127.0.0.1]) by vega.vega.com (8.12.6/8.12.5) with ESMTP id g9R9w9aJ036811; Sun, 27 Oct 2002 11:58:09 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Received: (from max@localhost) by vega.vega.com (8.12.6/8.12.5/Submit) id g9R9w8qs036810; Sun, 27 Oct 2002 11:58:08 +0200 (EET) Date: Sun, 27 Oct 2002 11:58:08 +0200 From: Maxim Sobolev To: Juli Mallett Cc: Nate Lawson , jlemon@FreeBSD.ORG, hackers@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC Message-ID: <20021027095808.GA36796@vega.vega.com> References: <3DB79DFA.FA719B8F@FreeBSD.org> <20021027075043.GA36533@vega.vega.com> <20021027010429.A90908@FreeBSD.org> <20021027082309.GC36533@vega.vega.com> <20021027012419.A94775@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20021027012419.A94775@FreeBSD.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Oct 27, 2002 at 01:24:19AM -0700, Juli Mallett wrote: > * De: Maxim Sobolev [ Data: 2002-10-27 ] > [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ] > > On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote: > > > * De: Maxim Sobolev [ Data: 2002-10-27 ] > > > [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ] > > > > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote: > > > > > On Thu, 24 Oct 2002, Maxim Sobolev wrote: > > > > > > Please review the patch, which adds two new types of events - > > > > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get > > > > > > notification when the image starts or stops executing. For example, it > > > > > > could be used to monitor that a daemon is up and running and notify > > > > > > administrator when for some reason in exits. I am running this code > > > > > > for more than a year now without any problems. > > > > > > > > > > > > Any comments and suggestions are welcome. > > > > > > > > > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you > > > > > want to write your own, couldn't you use waitpid()? Or a kevent() of > > > > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for > > > > > this. > > > > > > > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on > > > > vnodes - it is the main difference. Currently, you can't reliably > > > > get a notification when kernes started executing some arbitrary > > > > executable from your fs. > > > > > > This is not a job for the kernel, I don't think. > > > > Why not? Kernel now reports number of internal events via kqueue(2) interface, > > there is nothing wrong in adding yet another one. BTW, linux and irix already > > have similar functionality provided by /dev/imon. > > If you implemented a kq interface, and an imon wrapper, I'd be much more > impressed. A less-divergant interface to do this would be nice, even if > kq is the backing. In fact, especially if kq is the backing, kq is strong, > kq will make us smart. Actually, the only user of /dev/imon I am aware of is SGI's fam package (file alteration monitor). I've already implemented subset of it using BSD kqueue as a backend instead of imon. Check bsdfam project on sourceforge for details. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Oct 28 7:31:51 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A55137B401; Mon, 28 Oct 2002 07:31:49 -0800 (PST) Received: from mail.ubergeeks.com (lorax.ubergeeks.com [209.145.65.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92F6743E3B; Mon, 28 Oct 2002 07:31:48 -0800 (PST) (envelope-from adrian+freebsd-audit@ubergeeks.com) Received: from mail.ubergeeks.com (localhost [127.0.0.1]) by mail.ubergeeks.com (8.12.5/8.12.5) with ESMTP id g9SFVgel064168; Mon, 28 Oct 2002 10:31:42 -0500 (EST) (envelope-from adrian+freebsd-audit@ubergeeks.com) Received: from localhost (adrian@localhost) by mail.ubergeeks.com (8.12.5/8.12.5/Submit) with ESMTP id g9SFVfCq064165; Mon, 28 Oct 2002 10:31:42 -0500 (EST) (envelope-from adrian+freebsd-audit@ubergeeks.com) X-Authentication-Warning: lorax.ubergeeks.com: adrian owned process doing -bs Date: Mon, 28 Oct 2002 10:31:41 -0500 (EST) From: Adrian Filipi-Martin To: Juli Mallett Cc: Maxim Sobolev , Nate Lawson , , , Subject: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC In-Reply-To: <20021027010429.A90908@FreeBSD.org> Message-ID: <20021028102544.O64046-100000@lorax.ubergeeks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 Oct 2002, Juli Mallett wrote: > * De: Maxim Sobolev [ Data: 2002-10-27 ] > [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ] > > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote: > > > On Thu, 24 Oct 2002, Maxim Sobolev wrote: > > > > Please review the patch, which adds two new types of events - > > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get > > > > notification when the image starts or stops executing. For example, it > > > > could be used to monitor that a daemon is up and running and notify > > > > administrator when for some reason in exits. I am running this code > > > > for more than a year now without any problems. > > > > > > > > Any comments and suggestions are welcome. > > > > > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you > > > want to write your own, couldn't you use waitpid()? Or a kevent() of > > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for > > > this. > > > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on > > vnodes - it is the main difference. Currently, you can't reliably > > get a notification when kernes started executing some arbitrary > > executable from your fs. > > This is not a job for the kernel, I don't think. Implement it in userland > in terms of having the daemon write to a pidfile at startup, and have SIGUSR1 > make it tell the sender it's alive (using my sigq stuff this is trivial, just > send SIGUSR2 back), and periodically read the pidfile and try to communciate > with the daemon, and respawn it if it fails. This could be racey if done > poorly. However if you want this for *any* executable, rather than just > "some arbitrary executable" rather than some specific job, then while I wonder > how useful it is in a generic concept, the kq solution might be more > reasonable. > > Juli Mallett | FreeBSD: The Power To Serve Monitoring process health isn't nearly as intersting as being able to track system statistics for IDS purposes. STOP/START_EXEC tracking would make it much easier to profile a running system and then generate a statistical profile of what should normally be running. This cannot be accurately done outside the kernel. Adrian -- [ adrian@ubergeeks.com ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Oct 28 11: 0:43 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B86837B401 for ; Mon, 28 Oct 2002 11:00:42 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15E3243E42 for ; Mon, 28 Oct 2002 11:00:42 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g9SJ0fx3046979 for ; Mon, 28 Oct 2002 11:00:41 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g9SJ0f2n046963 for audit@freebsd.org; Mon, 28 Oct 2002 11:00:41 -0800 (PST) Date: Mon, 28 Oct 2002 11:00:41 -0800 (PST) Message-Id: <200210281900.g9SJ0f2n046963@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: audit@FreeBSD.org Subject: Current problem reports assigned to you Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [1999/01/28] bin/9770 audit An openpty(3) auxiliary program 1 problem total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Oct 28 20: 6:20 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73E8837B401 for ; Mon, 28 Oct 2002 20:06:18 -0800 (PST) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA3BD43E3B for ; Mon, 28 Oct 2002 20:06:17 -0800 (PST) (envelope-from fanf@chiark.greenend.org.uk) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 186Ndw-0001PD-00 (Debian); Tue, 29 Oct 2002 04:06:16 +0000 Date: Tue, 29 Oct 2002 04:06:16 +0000 From: Tony Finch To: freebsd-audit@freebsd.org Cc: dot@dotat.at Subject: uudecode paranoia Message-ID: <20021029040616.A3802@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Following on from http://www.kb.cert.org/vuls/id/336083 here is a candidate patch to make FreeBSD's uudecode paranoid about less-trusted filenames. Comments and suggestions are welcome, especially regarding the evil freopen hack. Tony. -- f.a.n.finch http://dotat.at/ WEST SOLE: SOUTHERLY VEERING NORTHEASTERLY 5 TO 7. RAIN THEN SHOWERS. MODERATE BECOMING GOOD. --- uudecode.c 11 Sep 2002 04:26:09 -0000 1.40 +++ uudecode.c 29 Oct 2002 04:01:06 -0000 @@ -59,6 +59,8 @@ #include #include +#include +#include #include #include #include @@ -152,7 +154,7 @@ int decode2(void) { - int base64, i; + int base64, i, flags; size_t n; char ch, *p, *q; void *mode; @@ -228,13 +230,42 @@ } if (!pflag) { - if (iflag && !access(buffn, F_OK)) { - warnx("not overwritten: %s", buffn); - return (0); + flags = O_WRONLY|O_CREAT|O_EXCL; + if (lstat(buffn, &st) == 0) { + if (iflag) { + warnc(EEXIST, "%s: %s", filename, buffn); + return (0); + } + switch (st.st_mode & S_IFMT) { + case S_IFREG: + case S_IFLNK: + /* avoid symlink attacks */ + if (unlink(buffn) == 0 || errno == ENOENT) + break; + warn("%s: unlink %s", filename, buffn); + return (1); + case S_IFDIR: + warnc(EISDIR, "%s: %s", filename, buffn); + return (1); + default: + if (oflag) { + /* trust command-line names */ + flags &= ~O_EXCL; + break; + } + warnc(EEXIST, "%s: %s", filename, buffn); + return (1); + } + } else if (errno != ENOENT) { + warn("%s: %s", filename, buffn); + return (1); } - if (freopen(buffn, "w", stdout) == NULL || - stat(buffn, &st) < 0 || (S_ISREG(st.st_mode) && - fchmod(fileno(stdout), getmode(mode, 0) & 0666) < 0)) { + if (fclose(stdout) != 0) + warn("problem writing output"); + /* Bah! there is no fdreopen or O_EXCL flag for fopen */ + i = open(buffn, flags, getmode(mode, 0) & 0666); + if (i < 0 || dup2(i, 1) < 0 || + freopen("/dev/stdout", "w", stdout) == NULL) { warn("%s: %s", filename, buffn); return (1); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message