dh, the daemon helper

On Nov 3, 6:10 pm, John Kelly <j...@isp2dial.com> wrote:[color=blue]
> On Nov 3, 6:13 am, vipps...@gmail.com wrote:
>[color=green][color=darkred]
> > > Nevertheless, if the value violates the isspace() constraint, the
> > > result is unpredictable. But how is that a defect?[/color][/color]
>[color=green]
> > It's a defect simply because the behavior is undefined.[/color]
>
> How can you call isspace() with EOF if the value is cast to unsigned?
> The "standard" sounds self contradictory.[/color]

The cast is done to ensure it's in the range [0, UCHAR_MAX].
If you know from before WHAT value your object holds, you can pass it
to isspace.
ie, these are valid

isspace(42);
isspace(EOF);
[color=blue][color=green]
> > The isspace() function shall return non-zero if c is a white-space character;
> > otherwise, it shall return 0.[/color]
>[color=green]
> > ERRORS[/color]
>[color=green]
> > No errors are defined.[/color]
>
> So the "standard" says be careful with your input, but if you don't,
> we won't say anything. Why follow a self contradictory standard, when
> it makes no sense?[/color]

These are not my words. Where did you get this from?
It won't mention ERRORS there.
read DESCRIPTION in <[url]http://www.opengroup.org/onlinepubs/009695399/[/url]
functions/isspace.html>
[color=blue]
> The c argument is an int, the value of which the application shall ensure is a character
> representable as an unsigned char or equal to the value of the macro EOF. If the argument
> has any other value, the behavior is undefined.[/color]

On Nov 3, 6:13 pm, vipps...@gmail.com wrote:[color=blue]
> On Nov 3, 5:52 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>[color=green]
> > Eric Sosman <Eric.Sos...@sun.com> writes:[/color]
>[color=green]
> > [...][/color]
>[color=green][color=darkred]
> > > Also, there's the smug satisfaction of knowing that the form I
> > > prefer will still work if ones' complement or signed magnitude
> > > machines ever make a comeback; that's pretty unlikely, but I've been
> > > in this industry long enough to realize that fashions come and go
> > > and return ...[/color][/color]
>[color=green]
> > The C-standard requires twos' complement for any implementation which
> > supports integer with any or all of the widths 8, 16, 32 and 64 (via
> > 7.18.1.1, 1 & 3).[/color]
>
> That's clearly wrong since it contradicts 7.18.1.1, p 3:
>[color=green]
> > These types are optional. However, if an implementation provides integer types with
> > widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a
> > two’s complement representation, it shall de�ne the corresponding typedef names.[/color]
>
> AFAIK[/color]


Sorry for this, I hit enter before completing the message.
Forget that "AFAIK".

You probably have a standard without the DR, since in that paragraph,
if I remember correctly, existed defficiencies.
(My quote is from n1256.pdf C99 TC3 with the relevant DRs)

John Kelly wrote:[color=blue]
> On Nov 3, 6:13 am, vipps...@gmail.com wrote:
>[color=green][color=darkred]
>>> Nevertheless, if the value violates the isspace() constraint, the
>>> result is unpredictable. But how is that a defect?[/color]
>> It's a defect simply because the behavior is undefined.[/color]
>
> How can you call isspace() with EOF if the value is cast to unsigned?
> The "standard" sounds self contradictory.[/color]

You can omit the cast if you're dealing not with a char value,
but with an int value that's already known to be in the proper range:

int ch; /* not "char ch" */
ch = getchar(); /* returns [0..UCHAR_MAX] or EOF */
if (isspace(ch)) ...
[color=blue]
> So the "standard" says be careful with your input, but if you don't,
> we won't say anything. Why follow a self contradictory standard, when
> it makes no sense?[/color]

You've misread the Standard.

It must be admitted that some unfortunate design can be found in
the Standard C library. The decision to flag end-of-file/error by
returning EOF is, with twenty-twenty hindsight, not one of the truly
wonderful ideas of all time. And the decision to make the <ctype.h>
functions accept EOF is even less defensible. IMHO, of course. Still,
that's not the Standard's fault: These things were designed long before
the Standard was written, and by that time the horse was gone from the
barn, the water was under the bridge, and où sont les neiges d'antan?

--
[email]Eric.Sosman@sun.com[/email]

On Nov 3, 11:16 am, vipps...@gmail.com wrote:
[color=blue][color=green][color=darkred]
> > > The isspace() function shall return non-zero if c is a white-space character;
> > > otherwise, it shall return 0.[/color][/color]
>[color=green][color=darkred]
> > > ERRORS[/color][/color]
>[color=green][color=darkred]
> > > No errors are defined.[/color][/color]
>[color=green]
> > So the "standard" says be careful with your input, but if you don't,
> > we won't say anything. Why follow a self contradictory standard, when
> > it makes no sense?[/color]
>
> These are not my words. Where did you get this from?
>
> read DESCRIPTION in <[url]http://www.opengroup.org/onlinepubs/009695399/[/url]
> functions/isspace.html>[/color]

Same link as yours:

[url]http://www.opengroup.org/onlinepubs/009695399/functions/isspace.html[/url]
[color=blue]
> It won't mention ERRORS there.[/color]

Mine says ERRORS.

Little did I suspect that my first post to c.u.p would produce this
level of discussion. Can we talk about dh, the daemon helper now? I
think it's a useful tool.

--
Webmail for Dialup Users
[url]http://www.isp2dial.com/freeaccounts.html[/url]

John Kelly <jak@isp2dial.com> writes:[color=blue]
> On Nov 3, 6:13 am, vipps...@gmail.com wrote:[color=green][color=darkred]
>> > Nevertheless, if the value violates the isspace() constraint, the
>> > result is unpredictable. But how is that a defect?[/color]
>>
>> It's a defect simply because the behavior is undefined.[/color]
>
> How can you call isspace() with EOF if the value is cast to unsigned?
> The "standard" sounds self contradictory.[/color]

The standard includes a requirement for the _value_ passed to is*,
namely, that it is either representable as an unsigned char or equal
to EOF. This means the value, if it is not equal to EOF, must be >= 0
and <= 255 (a UNIX(*)-'byte' is defined as having eight
bits). Otherwise, the behaviour of the is*-routine the argument is
passed to is undefined.

This does not mean that your code is 'defective' because of this, only
that the invariant condition mentioned above must be true.

Rainer Weikusat wrote:[color=blue]
> Eric Sosman <Eric.Sosman@sun.com> writes:
>
> [...]
>[color=green]
>> Also, there's the smug satisfaction of knowing that the form I
>> prefer will still work if ones' complement or signed magnitude
>> machines ever make a comeback; that's pretty unlikely, but I've been
>> in this industry long enough to realize that fashions come and go
>> and return ...[/color]
>
> The C-standard requires twos' complement for any implementation which
> supports integer with any or all of the widths 8, 16, 32 and 64 (via
> 7.18.1.1, 1 & 3).[/color]

Note that the cited text does *not* describe the `char' type,
but the optional fixed-width integer types. See 6.2.6.2p2, where
the three permitted representations for negative integers are
described.

--
[email]Eric.Sosman@sun.com[/email]

[email]vippstar@gmail.com[/email] wrote:[color=blue]
> On Nov 3, 5:39 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:[color=green]
>> vipps...@gmail.com wrote:[/color]
>
> <snip>
>[color=green][color=darkred]
>>> What I wanted to add is that, technically, (unsigned char)**ts is also
>>> undefined behavior;
>>> **ts is allowed to be a trap representation.
>>> It'd be more correct as *(unsigned char *)*ts.[/color]
>> If you're trying to classify a character that holds a trap
>> representation, your program is already in more trouble than a
>> few casts can cure. That is, the fact that your program is asking
>> about the space-ness or digit-ness of an uninitialized character
>> variable is evidence that it's already gone off the rails.[/color]
>
> You're mistaken, **ts is initialized, from user input.[/color]

If so (I haven't looked at the complete code), it cannot be a
trap representation and you need take no precautions to avoid
being trapped.

--
[email]Eric.Sosman@sun.com[/email]

On Nov 3, 6:45 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:[color=blue]
> vipps...@gmail.com wrote:[color=green]
> > On Nov 3, 5:39 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:[color=darkred]
> >> vipps...@gmail.com wrote:[/color][/color]
>[color=green]
> > <snip>[/color]
>[color=green][color=darkred]
> >>> What I wanted to add is that, technically, (unsigned char)**ts is also
> >>> undefined behavior;
> >>> **ts is allowed to be a trap representation.
> >>> It'd be more correct as *(unsigned char *)*ts.
> >> If you're trying to classify a character that holds a trap
> >> representation, your program is already in more trouble than a
> >> few casts can cure. That is, the fact that your program is asking
> >> about the space-ness or digit-ness of an uninitialized character
> >> variable is evidence that it's already gone off the rails.[/color][/color]
>[color=green]
> > You're mistaken, **ts is initialized, from user input.[/color]
>
> If so (I haven't looked at the complete code), it cannot be a
> trap representation and you need take no precautions to avoid
> being trapped.[/color]

I think it can, assuming that plain char is signed and signed char has
padding bits and the implementation allows any unsigned char value to
be read.

Rainer Weikusat <rweikusat@mssgmbh.com> writes:[color=blue]
>Eric Sosman <esosman@ieee-dot-org.invalid> writes:[color=green]
>> Rainer Weikusat wrote:[color=darkred]
>>> [... default suppression of core dumps ...]
>>> The problem with this approach is that it is not possible to decide
>>> beforehand when core dumps should rather have been enabled.[/color][/color]
>
>[...]
>[color=green]
>> Consider also the security and privacy implications. A
>> dump of a crashed program that was manipulating sensitive data
>> is likely to reveal the data -- quite possibly in unencrypted
>> form -- to anyone who gets a look at the core file.[/color]
>
>Keeping anything 'sensitive' on a time-shared system where
>untrustworthy people have 'superuser access' ('sufficient privileges
>to read arbitrary files belonging to other users') is basically a
>mistake (it is even a mistake when combined with MAC, because the
>software intended to enforce that could have errors).
>[/color]


Who said anything about "untrustworthy people with 'superuser access'"?

How about rootkits? How about zero-day exploits? What about daemons
not running with uid==0 that handle sensitive data and whose programmer
didn't think to use umask to ensure that the core file is protected?

You are grasping at straws.

scott

Scott Lurndal wrote:[color=blue]
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:[color=green]
>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:[color=darkred]
>>> Rainer Weikusat wrote:
>>>> [... default suppression of core dumps ...]
>>>> The problem with this approach is that it is not possible to decide
>>>> beforehand when core dumps should rather have been enabled.[/color]
>> [...]
>>[color=darkred]
>>> Consider also the security and privacy implications. A
>>> dump of a crashed program that was manipulating sensitive data
>>> is likely to reveal the data -- quite possibly in unencrypted
>>> form -- to anyone who gets a look at the core file.[/color]
>> Keeping anything 'sensitive' on a time-shared system where
>> untrustworthy people have 'superuser access' ('sufficient privileges
>> to read arbitrary files belonging to other users') is basically a
>> mistake (it is even a mistake when combined with MAC, because the
>> software intended to enforce that could have errors).
>>[/color]
>
>
> Who said anything about "untrustworthy people with 'superuser access'"?
>
> How about rootkits? How about zero-day exploits? What about daemons
> not running with uid==0 that handle sensitive data and whose programmer
> didn't think to use umask to ensure that the core file is protected?
>
> You are grasping at straws.[/color]

There are enough straws for all, I think. If you presuppose
malware running with elevated privileges, exposing sensitive data
in a core dump is the least of your worries.

I'm not trying to advance security/privacy as *the* reason or
even necessarily as a compelling reason to disable core dumps by
default, just as something that's worth taking into consideration.
I'm only trying to show that there's more to the decision than
"proactively shooting the mailman," as suggested up-thread.

--
[email]Eric.Sosman@sun.com[/email]

[email]scott@slp53.sl.home[/email] (Scott Lurndal) writes:[color=blue]
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:[color=green]
>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:[color=darkred]
>>> Rainer Weikusat wrote:
>>>> [... default suppression of core dumps ...]
>>>> The problem with this approach is that it is not possible to decide
>>>> beforehand when core dumps should rather have been enabled.[/color]
>>
>>[...]
>>[color=darkred]
>>> Consider also the security and privacy implications. A
>>> dump of a crashed program that was manipulating sensitive data
>>> is likely to reveal the data -- quite possibly in unencrypted
>>> form -- to anyone who gets a look at the core file.[/color]
>>
>>Keeping anything 'sensitive' on a time-shared system where
>>untrustworthy people have 'superuser access' ('sufficient privileges
>>to read arbitrary files belonging to other users') is basically a
>>mistake (it is even a mistake when combined with MAC, because the
>>software intended to enforce that could have errors).[/color]
>
>
> Who said anything about "untrustworthy people with 'superuser
> access'"?[/color]

I. There is nothing private on a computer system where untrustworthy
people have sufficient privileges to read the files of arbitrary users
or to debug processes created by arbitrary users, insofar the memory
of a running process isn't accessible otherwise, eg by going through a
suitable, virtual file (/proc/<pid>/mem on Linux). Hence claiming that
disabling certain debugging facilities (coredumps) would increase
'privacy' is wrong.

[color=blue]
> How about rootkits? How about zero-day exploits?[/color]

Strictly speaking, keeping sensitive data on a system accessible by
untrusted parties is such a mistake, too, because it is (at least
theoretically) possible that these 'untrusted parties' could manage to
elevate their own privileges by exploiting errors in software they
have been granted access to.

[color=blue]
> What about daemons not running with uid==0 that handle sensitive
> data and whose programmer didn't think to use umask to ensure that
> the core file is protected?[/color]

My umask is 0022, but the kernel I use nevertheless creates corefiles
with mode 0600. This must be handled by the kernel, because the umask
is supposed to affect files an application created in a controlled
way, while a coredump is a file created by the kernel after the
application cannot control anything anymore. The only other option
would be that all applications permanently have an umask of 0077, IOW,
that 'umask' as a usable feature wouldn't exist.

[email]vippstar@gmail.com[/email] wrote:[color=blue]
> On Nov 3, 6:45 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:[color=green]
>> vipps...@gmail.com wrote:[color=darkred]
>>> [...]
>>> You're mistaken, **ts is initialized, from user input.[/color]
>> If so (I haven't looked at the complete code), it cannot be a
>> trap representation and you need take no precautions to avoid
>> being trapped.[/color]
>
> I think it can, assuming that plain char is signed and signed char has
> padding bits and the implementation allows any unsigned char value to
> be read.[/color]

If you read it with getc/fgetc/getchar and store it into a
char and the implementation lets you get away with it (doesn't
trap on an out-of-range conversion, say), then the stored char
does not have a trap value. All the other C input functions are
defined as performing input "as if by fgetc," so it's not clear
how you expect them to produce trap values, either.

On the other hand, I'll concede that in comp.unix.programmer
there are ways to get input without going through the C library:
read, recv, mmap, ... carry no "as if by fgetc" language. So if
the input arrives by one of these other routes, then yes I guess
you're right. But I'll still maintain that it makes no sense to
apply toupper and friends to a character that might hold a trap
value, and that type-punning may make the trap go away but doesn't
render the program's behavior any more sensible. You can get
garbage with a possible alert or garbage with silence, but either
way it's garbage.

--
[email]Eric.Sosman@sun.com[/email]

On Nov 3, 12:46 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
[color=blue]
> You can get garbage with a possible alert or garbage with silence,
> but either way it's garbage.[/color]

Including null terminated strings in a language design was one of the
worst programming ideas, ever. When program correctness depends on the
value of some data, you're in big trouble to start with. Let's face
it, C is garbage. Getting a C program to do anything useful is a
reason to be happy.

My contribution to the garbage pile is dh, the daemon helper. Maybe
others will find it useful, as I have.

--
Webmail for Dialup Users
[url]http://www.isp2dial.com/freeaccounts.html[/url]

On Nov 3, 12:46 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
[color=blue]
> You can get garbage with a possible alert or garbage with silence,
> but either way it's garbage.[/color]

Including null terminated strings in a language design was one of the
worst programming ideas, ever. When program correctness depends on the
value of some data, you're in big trouble to start with. Let's face
it, C is garbage. Getting a C program to do anything useful is a
reason to be happy.

My contribution to the garbage pile is dh, the daemon helper. Maybe
others will find it useful, as I have.

P.S.

Sorry if this is a duplicate post, but posting via Google groups is
unreliable at times. And sadly, it's the only Usenet access I have
ATM. Maybe their system relies on some buggy C code, and got trapped
by my unconstrained input.

--
Webmail for Dialup Users
[url]http://www.isp2dial.com/freeaccounts.html[/url]

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[color=blue]
> [email]scott@slp53.sl.home[/email] (Scott Lurndal) writes:[color=green]
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:[color=darkred]
>>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>> Rainer Weikusat wrote:
>>>>> [... default suppression of core dumps ...]
>>>>> The problem with this approach is that it is not possible to decide
>>>>> beforehand when core dumps should rather have been enabled.
>>>
>>>[...]
>>>
>>>> Consider also the security and privacy implications. A
>>>> dump of a crashed program that was manipulating sensitive data
>>>> is likely to reveal the data -- quite possibly in unencrypted
>>>> form -- to anyone who gets a look at the core file.
>>>
>>>Keeping anything 'sensitive' on a time-shared system where
>>>untrustworthy people have 'superuser access' ('sufficient privileges
>>>to read arbitrary files belonging to other users') is basically a
>>>mistake (it is even a mistake when combined with MAC, because the
>>>software intended to enforce that could have errors).[/color]
>>
>>
>> Who said anything about "untrustworthy people with 'superuser
>> access'"?[/color]
>
> I. There is nothing private on a computer system where untrustworthy
> people have sufficient privileges to read the files of arbitrary users
> or to debug processes created by arbitrary users, insofar the memory
> of a running process isn't accessible otherwise, eg by going through a
> suitable, virtual file (/proc/<pid>/mem on Linux). Hence claiming that
> disabling certain debugging facilities (coredumps) would increase
> 'privacy' is wrong.
>
>[color=green]
>> How about rootkits? How about zero-day exploits?[/color]
>
> Strictly speaking, keeping sensitive data on a system accessible by
> untrusted parties is such a mistake, too, because it is (at least
> theoretically) possible that these 'untrusted parties' could manage to
> elevate their own privileges by exploiting errors in software they
> have been granted access to.[/color]

Right, so that leaves us with computers that are not on networks, locked
up in guarded rooms, and encased in concrete.

Security's not an all-or-nothing thing, you know, and it's more
complicated than just seeing who has root.

Imagine that users on System A occasionally remotely use some service on
System B, authenticated by passwords. Suppose the client program for
this service occasionally crashes. If core dumps are enabled, an
intruder on System A might be able to extract passwords and thus get
access to System B as well. However, if not, then the intruder would
have to wait until someone tried to access System B and sniff, trace, or
otherwise extract their password then. If the intruder is discovered
before this happens, System B is safe.

The security implication of core dumps is that they can mean sensitive
data is more persistent, and thus there is a larger window when it can
be got at.

By your argument, there's no reason to encrypt /etc/shadow either.

On Mon, 3 Nov 2008 10:28:45 -0800 (PST), John Kelly <jak@isp2dial.com> wrote:[color=blue]
> Sorry if this is a duplicate post, but posting via Google groups is
> unreliable at times. And sadly, it's the only Usenet access I have
> ATM. Maybe their system relies on some buggy C code, and got trapped
> by my unconstrained input.[/color]

FWIW, there are non-web-based news servers that are open for free
subscriptions and offer excellent services. For example, I am happily
using `news.sunsite.dk' with a "real" NNTP client for several years now,
and it has served me more than well I'd say :)

On Tue, 04 Nov 2008 05:37:31 +0200, Giorgos Keramidas
<keramida@ceid.upatras.gr> wrote:
[color=blue]
>On Mon, 3 Nov 2008 10:28:45 -0800 (PST), John Kelly <jak@isp2dial.com> wrote:[color=green]
>> Sorry if this is a duplicate post, but posting via Google groups is
>> unreliable at times. And sadly, it's the only Usenet access I have
>> ATM. Maybe their system relies on some buggy C code, and got trapped
>> by my unconstrained input.[/color]
>
>FWIW, there are non-web-based news servers that are open for free
>subscriptions and offer excellent services. For example, I am happily
>using `news.sunsite.dk' with a "real" NNTP client for several years now,
>and it has served me more than well I'd say :)[/color]

Ahh yes ... that's much better. Thanks for the tip.

I wonder why so many people like using web forums. I sure don't.


--
Webmail for Dialup Users
[url]http://www.isp2dial.com/freeaccounts.html[/url]

On Nov 3, 7:46 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:[color=blue]
> vipps...@gmail.com wrote:[color=green]
> > On Nov 3, 6:45 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:[color=darkred]
> >> vipps...@gmail.com wrote:
> >>> [...]
> >>> You're mistaken, **ts is initialized, from user input.
> >> If so (I haven't looked at the complete code), it cannot be a
> >> trap representation and you need take no precautions to avoid
> >> being trapped.[/color][/color]
>[color=green]
> > I think it can, assuming that plain char is signed and signed char has
> > padding bits and the implementation allows any unsigned char value to
> > be read.[/color]
>
> If you read it with getc/fgetc/getchar and store it into a
> char and the implementation lets you get away with it (doesn't
> trap on an out-of-range conversion, say), then the stored char
> does not have a trap value. All the other C input functions are
> defined as performing input "as if by fgetc," so it's not clear
> how you expect them to produce trap values, either.[/color]

Ah, you're right! I haven't thought of that.
[color=blue]
> On the other hand, I'll concede that in comp.unix.programmer
> there are ways to get input without going through the C library:
> read, recv, mmap, ... carry no "as if by fgetc" language. So if
> the input arrives by one of these other routes, then yes I guess
> you're right. But I'll still maintain that it makes no sense to
> apply toupper and friends to a character that might hold a trap
> value, and that type-punning may make the trap go away but doesn't
> render the program's behavior any more sensible. You can get
> garbage with a possible alert or garbage with silence, but either
> way it's garbage.[/color]

Alas, (or luckily?) CHAR_BIT is required to be 8 in POSIX.
<http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html>

Also
<http://www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap03.html>
[color=blue]
> Byte
> The restriction that a byte is now exactly eight bits was a conscious
> decision by the standard developers. It came about due to a combination
> of factors, primarily the use of the type int8_t within the networking
> functions and the alignment with the ISO/IEC 9899:1999 standard, where
> the intN_t types are now defined.[/color]

A char can't have any padding bits in POSIX, therefore the problem I
"solved" with type punning was imaginary.

On Nov 3, 8:28 pm, John Kelly <j...@isp2dial.com> wrote:[color=blue]
> On Nov 3, 12:46 pm, Eric Sosman <Eric.Sos...@sun.com> wrote:
>[color=green]
> > You can get garbage with a possible alert or garbage with silence,
> > but either way it's garbage.[/color]
>
> Including null terminated strings in a language design was one of the
> worst programming ideas, ever. When program correctness depends on the
> value of some data, you're in big trouble to start with. Let's face
> it, C is garbage. Getting a C program to do anything useful is a
> reason to be happy.[/color]

C serves its purpose well, it's not garbage. You haven't explained why
having such strings was one of the worst programming ideas ever, plus,
what alternatives do you have in mind?

Nate Eldredge <nate@vulcan.lan> writes:[color=blue]
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:[color=green]
>> [email]scott@slp53.sl.home[/email] (Scott Lurndal) writes:[color=darkred]
>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>>> Rainer Weikusat wrote:
>>>>>> [... default suppression of core dumps ...]
>>>>>> The problem with this approach is that it is not possible to decide
>>>>>> beforehand when core dumps should rather have been enabled.
>>>>
>>>>[...]
>>>>
>>>>> Consider also the security and privacy implications. A
>>>>> dump of a crashed program that was manipulating sensitive data
>>>>> is likely to reveal the data -- quite possibly in unencrypted
>>>>> form -- to anyone who gets a look at the core file.
>>>>
>>>>Keeping anything 'sensitive' on a time-shared system where
>>>>untrustworthy people have 'superuser access' ('sufficient privileges
>>>>to read arbitrary files belonging to other users') is basically a
>>>>mistake (it is even a mistake when combined with MAC, because the
>>>>software intended to enforce that could have errors).
>>>
>>>
>>> Who said anything about "untrustworthy people with 'superuser
>>> access'"?[/color]
>>
>> I. There is nothing private on a computer system where untrustworthy
>> people have sufficient privileges to read the files of arbitrary users
>> or to debug processes created by arbitrary users, insofar the memory
>> of a running process isn't accessible otherwise, eg by going through a
>> suitable, virtual file (/proc/<pid>/mem on Linux). Hence claiming that
>> disabling certain debugging facilities (coredumps) would increase
>> 'privacy' is wrong.
>>
>>[color=darkred]
>>> How about rootkits? How about zero-day exploits?[/color]
>>
>> Strictly speaking, keeping sensitive data on a system accessible by
>> untrusted parties is such a mistake, too, because it is (at least
>> theoretically) possible that these 'untrusted parties' could manage to
>> elevate their own privileges by exploiting errors in software they
>> have been granted access to.[/color]
>
> Right, so that leaves us with computers that are not on networks, locked
> up in guarded rooms, and encased in concrete.[/color]

Better fill the case with concrete instead. The only way something can
be made 'secure against abuse' is by eliminating 'use'. But you are
much more secure if you fill the computer case with concrete than if
you just randomly disable useful functionality.