FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-04-2010, 06:47 AM
Stéphane Glondu
 
Default pid file security

Yves-Alexis Perez a écrit :
> And you usually need root access for invoke-rc.d or /etc/init.d scripts
> (unless you have some kind of specific sudo permissions for that). So
> you might be able to kill other process as well.

I guess one (be it a human operator or a monit-like daemon) can be
easily fooled into restarting a service without checking.


Cheers,

--
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BDFC2FF.5080609@debian.org">http://lists.debian.org/4BDFC2FF.5080609@debian.org
 
Old 05-04-2010, 08:00 AM
Salvo Tomaselli
 
Default pid file security

On Tuesday 04 May 2010 08:25:25 Joey Hess wrote:
> Take a look in /var/run. Find a pid file that is owned by a non-root
> user. Now, look at the corresponding init script. What does it stop if
> that non-root user edited the pid file to contain '1'?

The fact that they are not owned by root doesn't mean you can edit them, they
would probably be owned by a specific user for that daemon and will not have
write access for others.
Have you found some with write permissions set to all?

Bye
--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005041000.13181.tiposchi@tiscali.it">http://lists.debian.org/201005041000.13181.tiposchi@tiscali.it
 
Old 05-04-2010, 09:47 AM
Philipp Kern
 
Default pid file security

On 2010-05-04, Salvo Tomaselli <tiposchi@tiscali.it> wrote:
> On Tuesday 04 May 2010 08:25:25 Joey Hess wrote:
>> Take a look in /var/run. Find a pid file that is owned by a non-root
>> user. Now, look at the corresponding init script. What does it stop if
>> that non-root user edited the pid file to contain '1'?
> The fact that they are not owned by root doesn't mean you can edit them, they
> would probably be owned by a specific user for that daemon and will not have
> write access for others.

So if I trick the daemon to write 1 to that file it's ok?

Sure, tricking a program into doing something the admin didn't
intend is a bug in itself, still we shouldn't leave that hole
open. (Putting the PID file a-w might help with that, though,
no?)

Kind regards,
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnhtvr9r.m67.trash@kelgar.0x539.de">http://lists.debian.org/slrnhtvr9r.m67.trash@kelgar.0x539.de
 
Old 05-04-2010, 04:14 PM
"brian m. carlson"
 
Default pid file security

On Tue, May 04, 2010 at 02:25:25AM -0400, Joey Hess wrote:
> Take a look in /var/run. Find a pid file that is owned by a non-root
> user. Now, look at the corresponding init script. What does it stop if
> that non-root user edited the pid file to contain '1'?

On Linux, nothing. From kill(2):

The only signals that can be sent to process ID 1, the init process,
are those for which init has explicitly installed signal handlers.
This is done to assure the system is not brought down accidentally.

Nevertheless, this could be a problem with other pids or on kfreebsd,
where the kernel will happily kill init and cause a panic.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 05-04-2010, 05:02 PM
Salvo Tomaselli
 
Default pid file security

On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote:
> Nevertheless, this could be a problem with other pids or on kfreebsd,
> where the kernel will happily kill init and cause a panic.
And the pid could still be set to something else than 1 and bring down
something important.

--
Salvo Tomaselli


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005041902.23653.tiposchi@tiscali.it">http://lists.debian.org/201005041902.23653.tiposchi@tiscali.it
 
Old 05-04-2010, 05:16 PM
"brian m. carlson"
 
Default pid file security

On Tue, May 04, 2010 at 07:02:23PM +0200, Salvo Tomaselli wrote:
> On Tuesday 04 May 2010 18:14:07 brian m. carlson wrote:
> > Nevertheless, this could be a problem with other pids or on kfreebsd,
> > where the kernel will happily kill init and cause a panic.
> And the pid could still be set to something else than 1 and bring down
> something important.

Which is exactly what I said: "this could be a problem with other pids".
I understand the implications that Joey was talking about, but I was
just pointing out that the particular example he gave was not the best
for his argument.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 05-05-2010, 08:17 AM
Goswin von Brederlow
 
Default pid file security

Stéphane Glondu <glondu@debian.org> writes:

> Yves-Alexis Perez a écrit :
>> And you usually need root access for invoke-rc.d or /etc/init.d scripts
>> (unless you have some kind of specific sudo permissions for that). So
>> you might be able to kill other process as well.
>
> I guess one (be it a human operator or a monit-like daemon) can be
> easily fooled into restarting a service without checking.
>
>
> Cheers,

If monit, runit, upstart, heartbeat or whatever is used to monitor
daemons does call stop+start then it is trivial. You are already the
user the daemon runs under (or you wouldn't have write permissions to
the pidfile) so just kill it. The next monitor run will then stop the
pid you wrote and restart the normal daemon wiping any trace of what you
did.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vdb2bw4w.fsf@frosties.localdomain">http://lists.debian.org/87vdb2bw4w.fsf@frosties.localdomain
 
Old 06-04-2010, 02:12 PM
Luke Kenneth Casson Leighton
 
Default pid file security

apologies for butting-in without being able to continue the thread,
but i've just seen this:
http://advogato.org/person/etbe/diary/779.html
which links to this:
http://lists.debian.org/debian-devel/2010/05/msg00067.html

can i please gently remind people that depinit solved the security and
fork-bombing issues years ago. i do keep mentioning depinit, on
debian lists, but there is typically absolutely zero response, which i
do not understand. nevertheless, as a debian and free software
advocate i feel compelled to keep pointing people at solutions: it's
up to you to investigate them.

depinit solved the fork-bombing issue because richard lightman was
concerned about attacks on his internet-facing system. richard added
code which actively tracks child signals (depinit is highly unusual
and innovative in that it catches ALL signals, and can therefore react
_to_ any signal) and analyses the timing etc. and provides a means to
trigger arbitrary "scripts" based on the signal type.

i recall a discussion with richard back in 2004/5 where he said that
when depinit is asked to stop a dependency/service, it does so by
first sending "graceful" signals, then goes on to take increasingly
aggressive action, including deciding, based on child-fork-bombing,
that a service has been corrupted and thus needs to be terminated with
extreme prejudice.

richard also solved the security PID problem ... by doing away with
the need for the PID file. in other words, a service is _always_ run
in "foreground" mode. if it dies (i.e. a segfault signal is caught),
the service is restarted automatically - by depinit (based on the
signal alone). thus, the need for safe_mysql goes away entirely; the
need for "apache2ctl start" goes away (i.e. you use apache2 -c
FOREGROUND=True or whatever it is) and so on. in this way, there
simply _is_ no need for a PID file, period. the relevant state
information is contained within depinit itself, and you can guarantee
that depinit will catch the signal.

one additional incredibly useful action of this "foregrounding"
approach to services was that he added the means to connect dependent
services via pipes, between their stdin and stdout.

the advantage of the entire services approach that richard took in
depinit is phenomenal: richard created dependent services where in
real-time you could script sshd's stdout (logging output) into
_another_ service, which was a shell-script that analysed the contents
and looked for "unauthorised login" attempts. more than three of
those occurring within a specified time, and iptables would be called
to block that user's IP address. voila: no delays due to syslog
polling: instant and real-time attacker blocking, all using simple
shell scripts. [the alternative - continuous polling and reading of
syslog entries - is just utterly messy, results in potential delays,
and requires that each and every "polling" program written for a
particular service understand the concept of syslog, how to read it,
how to read the last entries etc. etc. just... messy.]

so i feel compelled to point these things out, along with the other
incredible benefits that depinit brings including _massive_ reductions
in startup time (25 seconds on a 1.5ghz Pentium 4 when debian was
doing about 90 at the time), and phenomenal near-unbelievable
improvements in shutdown time (2 seconds on a 1.5ghz Pentium 4 when
debian was doing about 60 at the time), as it pains me to see depinit
being totally ignored and these security and painful issues being
discussed _years_ after a solution has already been done, and proven
to be effective.

you are welcome to contact me and discuss this further, if i can
remember any of the details i will be glad to describe them, and if
necessary go dig out the depinit scripts that i created for a KDE
debian desktop system, 4 years ago. which included solving the
udevsettle massive delay problems, by parallelising them and working
out the dependencies for critical startup services.

l.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTimPHZLoQS1KfvZIN2_Er_z2QFfhihhVNpq36z9M@mail .gmail.com">http://lists.debian.org/AANLkTimPHZLoQS1KfvZIN2_Er_z2QFfhihhVNpq36z9M@mail .gmail.com
 
Old 06-05-2010, 02:26 AM
Russell Coker
 
Default pid file security

On Sat, 5 Jun 2010, Luke Kenneth Casson Leighton <luke.leighton@gmail.com>
wrote:
> apologies for butting-in without being able to continue the thread,
> but i've just seen this:
> http://advogato.org/person/etbe/diary/779.html
> which links to this:
> http://lists.debian.org/debian-devel/2010/05/msg00067.html

http://etbe.coker.com.au/2010/06/04/securely-killing-processes/

You're quick. I had planned to announce my blog post on this list but forgot
before I went to bed last night. For reference the above URL is the best one
for my blog post as it allows you to enter comments.

> can i please gently remind people that depinit solved the security and
> fork-bombing issues years ago. i do keep mentioning depinit, on
> debian lists, but there is typically absolutely zero response, which i
> do not understand. nevertheless, as a debian and free software
> advocate i feel compelled to keep pointing people at solutions: it's
> up to you to investigate them.

http://sourceforge.net/projects/depinit/

The above URL is one place to download depinit. It's an init replacement that
uses configuration files to give the details of services to start.

> depinit solved the fork-bombing issue because richard lightman was
> concerned about attacks on his internet-facing system. richard added
> code which actively tracks child signals (depinit is highly unusual
> and innovative in that it catches ALL signals, and can therefore react
> _to_ any signal) and analyses the timing etc. and provides a means to
> trigger arbitrary "scripts" based on the signal type.

How does it do that? Does it ptrace them?

> i recall a discussion with richard back in 2004/5 where he said that
> when depinit is asked to stop a dependency/service, it does so by
> first sending "graceful" signals, then goes on to take increasingly
> aggressive action, including deciding, based on child-fork-bombing,
> that a service has been corrupted and thus needs to be terminated with
> extreme prejudice.

http://etbe.coker.com.au/2010/05/16/systemd-init/

How does it prevent processes escaping? Does it use cgroups as systemd does?
See the above URL for some of my thoughts about systemd.

> richard also solved the security PID problem ... by doing away with
> the need for the PID file.

That doesn't do away with the need for arbitrary programs to kill other
arbitrary programs and not make a mistake about which program they are
killing.

> in other words, a service is _always_ run
> in "foreground" mode. if it dies (i.e. a segfault signal is caught),
> the service is restarted automatically - by depinit (based on the
> signal alone). thus, the need for safe_mysql goes away entirely; the
> need for "apache2ctl start" goes away (i.e. you use apache2 -c
> FOREGROUND=True or whatever it is) and so on. in this way, there
> simply _is_ no need for a PID file, period. the relevant state
> information is contained within depinit itself, and you can guarantee
> that depinit will catch the signal.

systemd does all that.

> and looked for "unauthorised login" attempts. more than three of
> those occurring within a specified time, and iptables would be called
> to block that user's IP address. voila: no delays due to syslog
> polling: instant and real-time attacker blocking, all using simple

Does a program that uses inotify to wait for log file changes on disk
experience any delay of note?

> so i feel compelled to point these things out, along with the other
> incredible benefits that depinit brings including _massive_ reductions
> in startup time (25 seconds on a 1.5ghz Pentium 4 when debian was
> doing about 90 at the time), and phenomenal near-unbelievable
> improvements in shutdown time (2 seconds on a 1.5ghz Pentium 4 when
> debian was doing about 60 at the time), as it pains me to see depinit
> being totally ignored and these security and painful issues being
> discussed _years_ after a solution has already been done, and proven
> to be effective.

The systemd option of creating sockets before executing services that listen
to them seems to offer the potential of more significant boot performance
benefits than just starting things in parallel.

--
russell@coker.com.au
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201006051226.24353.russell@coker.com.au">http://lists.debian.org/201006051226.24353.russell@coker.com.au
 
Old 06-05-2010, 06:18 AM
Tollef Fog Heen
 
Default pid file security

]] Russell Coker

| > in other words, a service is _always_ run
| > in "foreground" mode. if it dies (i.e. a segfault signal is caught),
| > the service is restarted automatically - by depinit (based on the
| > signal alone). thus, the need for safe_mysql goes away entirely; the
| > need for "apache2ctl start" goes away (i.e. you use apache2 -c
| > FOREGROUND=True or whatever it is) and so on. in this way, there
| > simply _is_ no need for a PID file, period. the relevant state
| > information is contained within depinit itself, and you can guarantee
| > that depinit will catch the signal.
|
| systemd does all that.

More importantly: systemd _allows_ them to do that, it doesn't require
them. From the description of depinit, it sounds like it requires all
daemons to be modified.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ocfqhuiw.fsf@qurzaw.linpro.no">http://lists.debian.org/87ocfqhuiw.fsf@qurzaw.linpro.no
 

Thread Tools




All times are GMT. The time now is 09:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org