dh, the daemon helper - Unix

This is a discussion on dh, the daemon helper - Unix ; On Nov 3, 6:10 pm, John Kelly wrote: > On Nov 3, 6:13 am, vipps...@gmail.com wrote: > > > > Nevertheless, if the value violates the isspace() constraint, the > > > result is unpredictable. But how is that a ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 70

Thread: dh, the daemon helper

  1. Re: dh, the daemon helper

    On Nov 3, 6:10 pm, John Kelly wrote:
    > On Nov 3, 6:13 am, vipps...@gmail.com wrote:
    >
    > > > Nevertheless, if the value violates the isspace() constraint, the
    > > > result is unpredictable. But how is that a defect?

    >
    > > It's a defect simply because the behavior is undefined.

    >
    > How can you call isspace() with EOF if the value is cast to unsigned?
    > The "standard" sounds self contradictory.


    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);

    > > The isspace() function shall return non-zero if c is a white-space character;
    > > otherwise, it shall return 0.

    >
    > > ERRORS

    >
    > > No errors are defined.

    >
    > 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?


    These are not my words. Where did you get this from?
    It won't mention ERRORS there.
    read DESCRIPTION in <http://www.opengroup.org/onlinepubs/009695399/
    functions/isspace.html>

    > 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.


  2. Re: dh, the daemon helper

    On Nov 3, 6:13 pm, vipps...@gmail.com wrote:
    > On Nov 3, 5:52 pm, Rainer Weikusat wrote:
    >
    > > Eric Sosman writes:

    >
    > > [...]

    >
    > > > 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 ...

    >
    > > 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).

    >
    > That's clearly wrong since it contradicts 7.18.1.1, p 3:
    >
    > > 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 define the corresponding typedef names.

    >
    > AFAIK



    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)

  3. Re: dh, the daemon helper

    John Kelly wrote:
    > On Nov 3, 6:13 am, vipps...@gmail.com wrote:
    >
    >>> Nevertheless, if the value violates the isspace() constraint, the
    >>> result is unpredictable. But how is that a defect?

    >> It's a defect simply because the behavior is undefined.

    >
    > How can you call isspace() with EOF if the value is cast to unsigned?
    > The "standard" sounds self contradictory.


    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)) ...

    > 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?


    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
    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?

    --
    Eric.Sosman@sun.com

  4. Re: dh, the daemon helper

    On Nov 3, 11:16 am, vipps...@gmail.com wrote:

    > > > The isspace() function shall return non-zero if c is a white-space character;
    > > > otherwise, it shall return 0.

    >
    > > > ERRORS

    >
    > > > No errors are defined.

    >
    > > 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?

    >
    > These are not my words. Where did you get this from?
    >
    > read DESCRIPTION in <http://www.opengroup.org/onlinepubs/009695399/
    > functions/isspace.html>


    Same link as yours:

    http://www.opengroup.org/onlinepubs/...s/isspace.html

    > It won't mention ERRORS there.


    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
    http://www.isp2dial.com/freeaccounts.html


  5. Re: dh, the daemon helper

    John Kelly writes:
    > On Nov 3, 6:13 am, vipps...@gmail.com wrote:
    >> > Nevertheless, if the value violates the isspace() constraint, the
    >> > result is unpredictable. But how is that a defect?

    >>
    >> It's a defect simply because the behavior is undefined.

    >
    > How can you call isspace() with EOF if the value is cast to unsigned?
    > The "standard" sounds self contradictory.


    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.

  6. Re: dh, the daemon helper

    Rainer Weikusat wrote:
    > Eric Sosman writes:
    >
    > [...]
    >
    >> 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 ...

    >
    > 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).


    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.

    --
    Eric.Sosman@sun.com

  7. Re: dh, the daemon helper

    vippstar@gmail.com wrote:
    > On Nov 3, 5:39 pm, Eric Sosman wrote:
    >> vipps...@gmail.com wrote:

    >
    >
    >
    >>> 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.

    >
    > 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.

    --
    Eric.Sosman@sun.com

  8. Re: dh, the daemon helper

    On Nov 3, 6:45 pm, Eric Sosman wrote:
    > vipps...@gmail.com wrote:
    > > On Nov 3, 5:39 pm, Eric Sosman wrote:
    > >> vipps...@gmail.com wrote:

    >
    > >

    >
    > >>> 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.

    >
    > > 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.


    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.


  9. Re: dh, the daemon helper

    Rainer Weikusat writes:
    >Eric Sosman 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'"?

    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

  10. Re: dh, the daemon helper

    Scott Lurndal wrote:
    > Rainer Weikusat writes:
    >> Eric Sosman 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'"?
    >
    > 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.


    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.

    --
    Eric.Sosman@sun.com

  11. Re: dh, the daemon helper

    scott@slp53.sl.home (Scott Lurndal) writes:
    > Rainer Weikusat writes:
    >>Eric Sosman 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'"?


    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//mem on Linux). Hence claiming that
    disabling certain debugging facilities (coredumps) would increase
    'privacy' is wrong.


    > How about rootkits? How about zero-day exploits?


    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.


    > 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?


    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.

  12. Re: dh, the daemon helper

    vippstar@gmail.com wrote:
    > On Nov 3, 6:45 pm, Eric Sosman wrote:
    >> 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.

    >
    > 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.


    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.

    --
    Eric.Sosman@sun.com


  13. Re: dh, the daemon helper

    On Nov 3, 12:46 pm, Eric Sosman wrote:

    > You can get garbage with a possible alert or garbage with silence,
    > but either way it's garbage.


    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
    http://www.isp2dial.com/freeaccounts.html

  14. Re: dh, the daemon helper

    On Nov 3, 12:46 pm, Eric Sosman wrote:

    > You can get garbage with a possible alert or garbage with silence,
    > but either way it's garbage.


    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
    http://www.isp2dial.com/freeaccounts.html

  15. Re: dh, the daemon helper

    Rainer Weikusat writes:

    > scott@slp53.sl.home (Scott Lurndal) writes:
    >> Rainer Weikusat writes:
    >>>Eric Sosman 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'"?

    >
    > 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//mem on Linux). Hence claiming that
    > disabling certain debugging facilities (coredumps) would increase
    > 'privacy' is wrong.
    >
    >
    >> How about rootkits? How about zero-day exploits?

    >
    > 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.


    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.

  16. Google groups troubles [was: Re: dh, the daemon helper]

    On Mon, 3 Nov 2008 10:28:45 -0800 (PST), John Kelly wrote:
    > 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.


    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


  17. Re: Google groups troubles [was: Re: dh, the daemon helper]

    On Tue, 04 Nov 2008 05:37:31 +0200, Giorgos Keramidas
    wrote:

    >On Mon, 3 Nov 2008 10:28:45 -0800 (PST), John Kelly wrote:
    >> 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.

    >
    >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


    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
    http://www.isp2dial.com/freeaccounts.html


  18. Re: dh, the daemon helper

    On Nov 3, 7:46 pm, Eric Sosman wrote:
    > vipps...@gmail.com wrote:
    > > On Nov 3, 6:45 pm, Eric Sosman wrote:
    > >> 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.

    >
    > > 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.

    >
    > 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.


    Ah, you're right! I haven't thought of that.

    > 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.


    Alas, (or luckily?) CHAR_BIT is required to be 8 in POSIX.


    Also


    > 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.


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

  19. Re: dh, the daemon helper

    On Nov 3, 8:28 pm, John Kelly wrote:
    > On Nov 3, 12:46 pm, Eric Sosman wrote:
    >
    > > You can get garbage with a possible alert or garbage with silence,
    > > but either way it's garbage.

    >
    > 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.


    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?

  20. Re: dh, the daemon helper

    Nate Eldredge writes:
    > Rainer Weikusat writes:
    >> scott@slp53.sl.home (Scott Lurndal) writes:
    >>> Rainer Weikusat writes:
    >>>>Eric Sosman 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'"?

    >>
    >> 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//mem on Linux). Hence claiming that
    >> disabling certain debugging facilities (coredumps) would increase
    >> 'privacy' is wrong.
    >>
    >>
    >>> How about rootkits? How about zero-day exploits?

    >>
    >> 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.

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


    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.


+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast