Hello!
Is it possible to prevent a program to be straced on x86?
What do I have to do, eg., to prevent a perl-program to be straced?
Thanks for any hint,
kind regards,
Andreas Hartmann
On 9/3/05, Andreas Hartmann <[email protected]> wrote:
> Hello!
>
> Is it possible to prevent a program to be straced on x86?
> What do I have to do, eg., to prevent a perl-program to be straced?
>
So that none can see what are you doing? Or because your program is
breaking because of this? Probably nothing, but someone would like
to know what it is you are doing and exactly how it breaks (and, if
you don't mind -
why it breaks).
Actuall, you can prevent a program of being straced (or debugged, for
that matter):
run it as another user. Root still can strace anything, though.
Alex Riesen wrote:
> On 9/3/05, Andreas Hartmann <[email protected]> wrote:
>> Hello!
>>
>> Is it possible to prevent a program to be straced on x86?
>> What do I have to do, eg., to prevent a perl-program to be straced?
>>
>
> So that none can see what are you doing? Or because your program is
> breaking because of this? Probably nothing, but someone would like
> to know what it is you are doing and exactly how it breaks (and, if
> you don't mind -
> why it breaks).
That's not really the problem. I want to hide a clear text password in
that program (something like ssh-agent or gpg-agent; the last can be
straced, too :-() which I need for a database when the program runs.
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.
Kind regards,
Andreas Hartmann
> 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).
Can I ask why you want to hide the database password from root?
Regards,
Chase Venters
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.
Kind regards,
Andreas Hartmann
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
Hi Andreas,
On Sun, Sep 04, 2005 at 09:32:34AM +0200, Andreas Hartmann wrote:
> > 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.
Then you're loosing your time. If the user gains root privileges, then he
can do what he wants to get the password, including loading modules or
scanning the memory. For instance, it happened to me several times that
my browser crashed during a post with a very long message. Not funny at
all. Then, as root, I started my hex editor and scaned all memory for
words I was sure I wouldn't find anywhere else, and then I could restore
my data by hand. Doing so to find a password is pretty easy too. And don't
tell me that it's deleted very soon, because it's also possible to send
lots of SIGSTOP/scan/SIGCONT very fast to try to catch the clear password.
> 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.
can't you use a specific password just for this app ? or use another server
on which no user has access to relay your connections and insert the right
password itself ?
Regards,
Willy
Andreas Hartmann <[email protected]> wrote:
1> Alex Riesen wrote:
> > On 9/3/05, Andreas Hartmann <[email protected]> wrote:
> >> Hello!
> >> Is it possible to prevent a program to be straced on x86?
> >> What do I have to do, eg., to prevent a perl-program to be straced?
Look at the contortions shc does for this.
> > So that none can see what are you doing? Or because your program is
> > breaking because of this? Probably nothing, but someone would like
> > to know what it is you are doing and exactly how it breaks (and, if
> > you don't mind -
> > why it breaks).
> That's not really the problem. I want to hide a clear text password in
> that program (something like ssh-agent or gpg-agent; the last can be
> straced, too :-() which I need for a database when the program runs.
Anyone who can read the executable can find that out. In the worst case, by
running it in a doctored environment that catches the password.
Place it in a file that noone else can read, that way it is also easier to
change.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Sun, 2005-09-04 at 09:32 +0200, Andreas Hartmann wrote:
> Chase Venters wrote:
[...]
> >
> > 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
Forget it.
You cannot hide anything seriously from root (or equivalent users on
other OSes and so-called OSes) with such attempts (independent how the
process got root - with the correct password or through a security hole
somewhere).
Consider the case that root installed a (patched) DB-server which dumps
the passwords in some logfile. Or root logs from the authentication
framework (be it PAM or something else)
> 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.
So either you get your own machine or you use different passwords for
different services.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services