| Author |
Message |
BarryK
Puppy Master

Joined: 09 May 2005 Posts: 6866 Location: Perth, Western Australia
|
Posted: Sat 21 Jan 2006, 19:43 Post subject:
How can I prevent a process from being killed? |
|
I've got this "dnotify" daemon that monitors directories and
will warn if system directories are modified.
I don't want the root user to be able to kill this process.
Note, for people who want absolute control, including being
able to kill dnotify or modify it's behaviour, this will still be possible
by modifying a boot script, but not after Puppy has booted.
Does anyone know how or if it is possible to make a process
unkillable?
If it can't be done, I will probably have to dump using dnotify,
and instead go for dazuki, which is a kernel module that has the
same monitoring capability as dnotify.
|
|
Back to top
|
|
 |
drongo

Joined: 10 Dec 2005 Posts: 328 Location: UK
|
Posted: Sat 21 Jan 2006, 20:40 Post subject:
|
|
I have no idea how you would do this, but could you "spoof" a zombie process? Then it would be difficult to kill.
Otherwise, I think you have to use a kernel process?
Or maybe there is a way of hiding a running process?
|
|
Back to top
|
|
 |
GuestToo
Puppy Master
Joined: 04 May 2005 Posts: 4078
|
Posted: Sun 22 Jan 2006, 01:24 Post subject:
|
|
can it be started from inittab so that it will automatically be respawned if it's killed?
by the way, kill -18 1 might be able to kill zombie processes without rebooting
|
|
Back to top
|
|
 |
Lobster
Official Crustacean

Joined: 04 May 2005 Posts: 15109 Location: Paradox Realm
|
Posted: Sun 22 Jan 2006, 03:27 Post subject:
|
|
You can not kill what does not exist
or what is already dead
or what is something else
It would seem to be safer to do this from the kernel
maybe these guys
http://www.linuxsecurity.com/
I am out of my depth but using this
http://www.google.com/linux
with these search parameters
http://www.cyberwyre.com/data-mining-using-google/
might give something better than:
Concurrency
| Quote: |
Non-interruptible operations are a good way to create unkillable processes
If your code calls wait_for_completion and nobody ever completes the task, the result will be an unkillable process. |
_________________ Puppy WIKI
|
|
Back to top
|
|
 |
Mathiasdm
Joined: 05 May 2005 Posts: 100
|
Posted: Sun 22 Jan 2006, 08:28 Post subject:
|
|
Might be a bit of long way, but:
look for a program that can respawns dnotify as soon as it's killed.
Make the program run twice, so it respawns itself too, if one of the processes is killed.
Or would it be possible to kill both processes at once? I fear it will
|
|
Back to top
|
|
 |
BarryK
Puppy Master

Joined: 09 May 2005 Posts: 6866 Location: Perth, Western Australia
|
Posted: Sun 22 Jan 2006, 18:23 Post subject:
|
|
| GuestToo wrote: | | can it be started from inittab so that it will automatically be respawned if it's killed? |
Puppy2 has inittab in the "working" environment after
pivot_root has taken place.
I'm launching dnotify before the pivot_root, but then the pivot_root takes place and init is run, using the inittab in the working environment.
As a writable tmpfs layer in the working environment is on "/"
(by unionfs), everything is now writable, including inittab.
The unionfs layers look like this:
tmpfs layer in ram
persistent storage
squashfs puppy file
Unionfs and these layers are setup before the pivot_root, and although initab is writable, it is easy enough to delete any modification to it in the tmpfs or persistent-storage layers, before the pivot_root takes place.
...meaning, inittab can be kept pristine.
G2, that means that your respawn idea seems like a goer.
The thing is though, how will init/inittab behave if it sees
dnotify already running (as it got launched before the
pivot_root)?
|
|
Back to top
|
|
 |
BarryK
Puppy Master

Joined: 09 May 2005 Posts: 6866 Location: Perth, Western Australia
|
Posted: Sun 22 Jan 2006, 18:28 Post subject:
|
|
Ha ha, this leads to another problem.
The initial ramdisk stays in ram, and is read-only.
The unionfs operation takes place in the initial ramdisk, before
the pivot_root.
The initial ramdisk is supposed to remain pristine, untouchable,
but what is to stop anybody from remounting it read-write?
I need some way of blocking that too.
After pivot_root, the initial ramdisk is readily accessable, as /initrd.
Well, it will be pristine at bootup, because it is just the
initrd.gz file (similar to image.gz). But, I don't want anyone to be able to fiddle with the contents of the initial ramdisk after pivot_root has taken place, as that will be a security weakness.
|
|
Back to top
|
|
 |
Neutered
Guest
|
Posted: Sun 22 Jan 2006, 23:01 Post subject:
|
|
There suddenly seems to be obsession about "possible security weaknessess in Puppy.
Lets hope we are not falling into the "Windows" scaremongering tactics where everybody who uses Windows is conned into using no end of -
Virus
Trojan
Rootkit
Spyware
Browser Protection
Intrusion Prevention
Detection Utilities..... etc etc etc programs.
I ask
Has Puppy got fleas
Has Puppy been wormed
Is Puppy about to be neuterd and muzzled
Come on chaps lets keep Puppy "rooted" as it were.
Is there any evidence that Puppy has ever been compromised
If those doomsday Puppy gurus have their way then Puppy will become an overburdened sad pityful image of itself, yelping and crying
"Do touch me I might have worms"
Despatch PupSafe where it belongs in the Doggie Bin and let Puppy get back to enjoying himself, frisky, carefree, playful and with the attitude
"If you want to neuter me you will have to catch me first"
|
|
Back to top
|
|
 |
Lobster
Official Crustacean

Joined: 04 May 2005 Posts: 15109 Location: Paradox Realm
|
Posted: Sun 22 Jan 2006, 23:57 Post subject:
|
|
I agree that a balance between
FUD (Fear, Uncertainty, Doubt)
and
DUF (Dumb unchecked freedom)
is not always the issue
Puppy works because the components are integrated and
required components are addressed and implemented. When I start a new (clean install of Puppy) before going on the net I install the firewall from setup. I find that is sufficient.
Puppy2 is implementing security [shrug] because it is different or perhaps even revolutionary as Barry says. Good news as far as most of us are concerned, as things have worked fine up to now, long may it continue . . .
_________________ Puppy WIKI
|
|
Back to top
|
|
 |
Softy
Guest
|
Posted: Mon 23 Jan 2006, 02:51 Post subject:
|
|
I don't wish to be flippant (security is an important issue) but somebody on the forum mentioned a "Hardened version of Puppy".
Puppy with a "Permanent Hard-on"...... he should be so lucky (but uncomfortable).
Perhaps as Lobster suggests (shrug) Puppy2 will need some extra security.
My hope is that Puppy2 doesn't get bogged down in obsessive security issues.
Puppy is not even a blip on the radar screen as far as potential hackers are concerned, they have bigger Vista to work on.
|
|
Back to top
|
|
 |
|