From: Tejun Heo <htejun@gmail.com>
To: Andreas Hartmann <andihartmann@01019freenet.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: forbid to strace a program
Date: Sun, 4 Sep 2005 17:47:32 +0900 [thread overview]
Message-ID: <20050904084732.GA30256@htj.dyndns.org> (raw)
In-Reply-To: <dfe7ui$14q$1@pD9F874C0.dip0.t-ipconnect.de>
On Sun, Sep 04, 2005 at 09:32:34AM +0200, Andreas Hartmann wrote:
> Chase Venters wrote:
> >> Is there another way to do this? If the password is crypted, I need a
> >> passphrase or something other to decrypt it again. Not really a solution
> >> of the problem.
> >>
> >> Therefore, it would be best, to hide it by preventing stracing of the
> >> application to all users and root.
> >>
> >> Ok, root could search for the password directly in the memory, but this
> >> would be not as easy as a strace.
> >
> > Obfuscation isn't really valid security. Making something 'harder' to break
> > isn't a solution unless you're making it hard enough that current technology
> > can't break it (eg... you always have the brute force option, but good crypto
> > intends to make such an option impossible without expending zillions of clock
> > cycles).
>
> You're right. If I would have a solution, which could do this, I would
> prefer it.
>
> >
> > Can I ask why you want to hide the database password from root?
>
> It's easy: for security reasons. There could always be some bugs in some
> software, which makes it possible for some other user, to gain root
> privileges. Now, they could easily strace for information, they shouldn't
> could do it. The password they could see, isn't just used for the DB, but
> for some other applications, too. That's the disadvantage of general
> (single sign on) passwords.
>
I'm no security expert, but if root privileges are compromised,
there's no way to plug anything. A kernel module can be loaded to do
just about anything. Signals can be sent to obtain core dumps.
Binaries can be switched. Network traffics can be sniffed. Kernel
image can be replaced and rebooted while no one is watching without
leaving any record.
If security is important for your application, move the application
into a separate machine in a physically protected place and use very
restrictive firewall. Plugging strace() will make little (if any)
change w.r.t. security.
--
tejun
next prev parent reply other threads:[~2005-09-04 8:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4IOGw-1DU-11@gated-at.bofh.it>
[not found] ` <4IOGw-1DU-13@gated-at.bofh.it>
[not found] ` <4IOGw-1DU-9@gated-at.bofh.it>
[not found] ` <4IOQc-1Pk-23@gated-at.bofh.it>
2005-09-04 7:32 ` forbid to strace a program Andreas Hartmann
2005-09-04 8:45 ` Willy Tarreau
2005-09-04 8:47 ` Tejun Heo [this message]
2005-09-05 9:36 ` Bernd Petrovitsch
[not found] <4IExJ-4aE-21@gated-at.bofh.it>
[not found] ` <4IMY1-7C1-19@gated-at.bofh.it>
2005-09-03 22:23 ` Andreas Hartmann
2005-09-03 22:34 ` Chase Venters
2005-09-04 21:47 ` Horst von Brand
2005-09-03 11:28 Andreas Hartmann
2005-09-03 20:29 ` Alex Riesen
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=20050904084732.GA30256@htj.dyndns.org \
--to=htejun@gmail.com \
--cc=andihartmann@01019freenet.de \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox