Loading ...
Sorry, an error occurred while loading the content.
 

Re: Root privileges

Expand Messages
  • Michael J Wise
    ... Short answers from Victor are a good sign that you ve headed down the wrong track. :) There s a reason that Postfix was once known by another name. ...
    Message 1 of 13 , Jan 30, 2011
      On Jan 30, 2011, at 6:50 PM, Chris Tandiono wrote:

      > On 30 Jan 2011, at 18:46 , Victor Duchovni wrote:
      >
      >> On Mon, Jan 31, 2011 at 08:02:28AM +0530, varad gupta wrote:
      >>
      >>> Thanx for all the replies - I now understand the reason for master
      >>> daemon to run with superuser privileges. They were really helpful.
      >>>
      >>> But then, is postfix not running the same risk as "sendmail" ?
      >>
      >> No.

      Short answers from Victor are a good sign that you've headed down the wrong track. :)
      There's a reason that Postfix was once known by another name.

      >>> Does it mean, that unless run in a chroot environment, postfix is
      >>> susceptible to the same risks as sendmail and gives an attacker
      >>> capability of causing similar damage (despite having a far better
      >>> system of tasks divided amongst various unprivileged processes
      >>> designed to perform specific tasks) ?
      >>
      >> No.

      Here's the first hint, you're comparing Oranges with Orangutans.
      You say that Sendmail is a monolithic process running as root, and Postfix' Master process is running as root, so they are thus open to the same sorts of problems.

      You are grossly incorrect.

      To put it in another way, what vulnerabilities is the Master process exposed to? It doesn't talk to the internet, it doesn't talk to the local user. Almost all the interactions it has with anything are done via processes running with less privilege.

      > I don't know how accurate my interpretation is, but the way I see it, postfix's master process, if hacked, would obviously present a lot of problems. But since it does less, it's also less open to hacks. For example, an empty program that does nothing cannot be hacked or exploited in any way because there is nothing to exploit. By moving most of the functions out of the master process, even if the other processes have flaws, they aren't privileged.
      >
      > Someone else can feel free to correct me.

      Sounds about right.

      Another point... is there any record AT ALL of Postfix ever being hacked?
      Sendmail ... we don't have time to recount all the hacks, and quite frankly, I don't know where one would go to get a list, but I know that anything less than version 8.8.8 was considered un-secure by definition, and that was about when I stopped keeping track way back then. Have never heard anything about Postfix.

      Aloha,
      Michael.
      --
      "Please have your Internet License http://kapu.net/~mjwise/
      and Usenet Registration handy..."
    • Morten P.D. Stevens
      ... Sendmail is not a security risk. These are old horror stories. Why use big companies like IBM or Red Hat still sendmail when postfix is supposed to be so
      Message 2 of 13 , Jan 30, 2011
        2011/1/31 varad gupta <postfix.vbg@...>:
        >
        > But then, is postfix not running the same risk as "sendmail" ?

        Sendmail is not a security risk. These are old horror stories. Why use big companies like IBM or Red Hat still sendmail when postfix is supposed to be so much safer? Why is sendmail the default MTA on Solaris, AIX, FreeBSD, RHEL and some more. Because it is unsafe?

        There is no software without vulnerabilities.

        Whatever you use, postfix or sendmail ... the theoretical risk of attack is exactly the same.

        Best regards,

        Morten
      • Victor Duchovni
        ... This is nonsense, design matters. Some software is safer by design. Implementation flaws are still possible, but in *safer by design* software they are
        Message 3 of 13 , Jan 31, 2011
          On Mon, Jan 31, 2011 at 05:06:08AM +0100, Morten P.D. Stevens wrote:

          > Whatever you use, postfix or sendmail ... the theoretical risk of
          > attack is exactly the same.

          This is nonsense, design matters. Some software is safer by design.

          Implementation flaws are still possible, but in *safer by design*
          software they are less frequent, and have lower impact.

          --
          Viktor.
        • Wietse Venema
          ... We should close this thread. Wietse
          Message 4 of 13 , Jan 31, 2011
            Victor Duchovni:
            > On Mon, Jan 31, 2011 at 05:06:08AM +0100, Morten P.D. Stevens wrote:
            >
            > > Whatever you use, postfix or sendmail ... the theoretical risk of
            > > attack is exactly the same.
            >
            > This is nonsense, design matters. Some software is safer by design.
            >
            > Implementation flaws are still possible, but in *safer by design*
            > software they are less frequent, and have lower impact.

            We should close this thread.

            Wietse
          • varad gupta
            Thanx for all the responses, especially Daniel. And as Wietse says, lets close the thread... Regards
            Message 5 of 13 , Jan 31, 2011
              Thanx for all the responses, especially Daniel.

              And as Wietse says, lets close the thread...

              Regards

              On Tue, Feb 1, 2011 at 2:00 AM, Wietse Venema <wietse@...> wrote:
              > Victor Duchovni:
              >> On Mon, Jan 31, 2011 at 05:06:08AM +0100, Morten P.D. Stevens wrote:
              >>
              >> > Whatever you use, postfix or sendmail ... the theoretical risk of
              >> > attack is exactly the same.
              >>
              >> This is nonsense, design matters. Some software is safer by design.
              >>
              >> Implementation flaws are still possible, but in *safer by design*
              >> software they are less frequent, and have lower impact.
              >
              > We should close this thread.
              >
              >        Wietse
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.