Jim, No, because those processes would be children of init, not init itself.
Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCM d- s:+ a--- C++++ UL++++ P L+++ E W++ N o-- K- w O--- M- V- PS+ PE- Y PGP t+ 5 X- R tv+ b DI--- D+ G e-- h++ r--- y ------END GEEK CODE BLOCK------ On Fri, 28 Apr 2000, Jim Breton wrote: > On Thu, Apr 27, 2000 at 11:44:23PM -0700, Alexander Hvostov wrote: > > Not the capability _bounding_ set. Check the 'lcap' package. The only time > > the capabilities are restored is when the machine is rebooted, and only a > > process which originated as a kernel thread (i.e., init, kswapd, etc) can > > restore capabilities without a reboot. None of those programs will do > > this, so make /sbin/init immutable (which it should be anyway), and your > > system is pretty much air-tight, as far as remote attacks go. > > Thanks, I just downloaded the source and will start messing with it. > I've found various other cap utils around the 'net in scattered places > too. > > Regarding which processes can change caps: couldn't one set up an > additional runlevel that would contain a few scripts to set > capabilities, then run "telinit 8" (for example)? The init process > would be executing those scripts and could therefore alter the > capabilities, no? > > Just trying to get a better handle on this. :) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
