All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Sinz <msinz@wgate.com>
To: Peter Waltenberg <pwalten@au1.ibm.com>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: Core dump
Date: Fri, 15 Feb 2002 22:24:29 -0500	[thread overview]
Message-ID: <3C6DD0ED.E2D31059@wgate.com> (raw)
In-Reply-To: <OF615DC251.A04042B9-ON4A256B61.007D0561-4A256B61.007D5D7B@au.ibm.com>

Peter Waltenberg wrote:
> 
> Whats to stop someone creating a process (or a nodename) with an inspired
> (tm) name, and trashing or overwriting system files ?
> 
>      %P      The Process ID (current->pid)
>         %U      The UID of the process (current->uid)
>         %N      The command name of the process (current->comm)
>         %H      The nodename of the system (system_utsname.nodename)
>         %%      A "%"
> 
> The flexibility is nice, but can you PROVE it doesn't have holes like that
> ?

Actually - yes.

First, I can not prevent some system admin from making the core pattern
a bad pattern.  For example, a pattern of /usr/bin/%N would be a bad thing (tm)

However, as long as the system admin (who is the person who can set the pattern)
does not do that, the code prevents a rouge name (hostname or command name)
from causing problems.

(I prevent the use of "/" in either the hostname or command name, for example)

I have tried most everything I could think of.  And, since the host name is
usually not setable by non-root, it makes it even less likely.

In fact, with a pattern like /corefiles/%H-%N-%P.core, there is even less
likelyhood that a coredump can cause problems since I can make the /corefiles
partition its own location and thus coredumps will not write to the key
filesystem.

BTW - both FreeBSD and OpenBSD have a simular format (I took my insperation
from FreeBSD, which I always liked better since the default there is %N.core)

> Just about everything we've had with variable logfile names has had holes
> like that. Samba is one of the more recent examples.

The key is to filter certain characters.  Mostly the '/' in any of the
variables.

However, there is always the problem of someone with root access making
a bad setting in the sysctl.  But then, if they have root, they don't
need to set some sysctl in order to cause damage.

-- 
Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com
A master's secrets are only as good as
	the master's ability to explain them to others.

       reply	other threads:[~2002-02-16  3:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF615DC251.A04042B9-ON4A256B61.007D0561-4A256B61.007D5D7B@au.ibm.com>
2002-02-16  3:24 ` Michael Sinz [this message]
2007-02-06  2:12 core dump Stefanos Harhalakis
2007-02-06 12:40 ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C6DD0ED.E2D31059@wgate.com \
    --to=msinz@wgate.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pwalten@au1.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.