Mailing List Archive

On Thu, 2003-08-07 at 15:48, Anthony.Golia@morganstanley.com wrote:
> privs_init: could not lookup user zebra
>
> can it be configed to just run as root?


configure --help tells you:
--enable-user=ARG user to run zebra suite as (default zebra)
--enable-group=ARG group to run zebra suite as (default zebra)


but why would you want to run it as root if you can run it as a normal
user!?

Regards,

Teun Vink
Luna.nl NOC

thx, i should've seen that. believe it or not, it's easier for me to
just run it as root than create a new user. what's the down side to
running it as root?

Teun Vink wrote:
> On Thu, 2003-08-07 at 15:48, Anthony.Golia@morganstanley.com wrote:
>
>>privs_init: could not lookup user zebra
>>
>>can it be configed to just run as root?
>
>
>
> configure --help tells you:
> --enable-user=ARG user to run zebra suite as (default zebra)
> --enable-group=ARG group to run zebra suite as (default zebra)
>
>
> but why would you want to run it as root if you can run it as a normal
> user!?
>
> Regards,
>
> Teun Vink
> Luna.nl NOC
>
>
> _______________________________________________
> Quagga-users mailing list
> Quagga-users@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-users
>
>


--
Cheers,
Anthony

On Thursday, August 07, 2003 4:04 PM, Anthony.Golia@morganstanley.com
<Anthony.Golia@morganstanley.com> wrote:
> thx, i should've seen that. believe it or not, it's easier for me to
> just run it as root than create a new user. what's the down side to
> running it as root?
>

You are far more open for attacks as all the processes have root privileges
...


Arnold

On Thu, 7 Aug 2003 Anthony.Golia@morganstanley.com wrote:

> thx, i should've seen that. believe it or not, it's easier for me to
> just run it as root than create a new user. what's the down side to
> running it as root?

any exploits means the attacker gets root privileges?

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Violence is a sword that has no handle -- you have to hold the blade.

makes sense i'll add a user. how can it add routes to the kernel as non
root though?

Paul Jakma wrote:
> On Thu, 7 Aug 2003 Anthony.Golia@morganstanley.com wrote:
>
>
>>thx, i should've seen that. believe it or not, it's easier for me to
>>just run it as root than create a new user. what's the down side to
>>running it as root?
>
>
> any exploits means the attacker gets root privileges?
>
> regards,


--
Cheers,
Anthony

On Thu, 7 Aug 2003 Anthony.Golia@morganstanley.com wrote:

> makes sense i'll add a user. how can it add routes to the kernel as non
> root though?

because you start it up as root so that it can set things up so as to
allow it to temporarily change back to root for those times it needs
to. in normal operation it runs as something else.

on linux, with libcap installed, it will use capabilities instead,
and drop all capabilities, only retaining the few it needs in its
permitted set. under normal operation it runs non-root,
no-capabilities. temporarily raising the few capabilities it needs as
required.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Conquering Russia should be done steppe by steppe.

On Thu, 2003-08-07 at 10:51, Paul Jakma wrote:
> On Thu, 7 Aug 2003 Anthony.Golia@morganstanley.com wrote:
>
> > makes sense i'll add a user. how can it add routes to the kernel as non
> > root though?
>
> because you start it up as root so that it can set things up so as to
> allow it to temporarily change back to root for those times it needs
> to. in normal operation it runs as something else.
>
> on linux, with libcap installed, it will use capabilities instead,
> and drop all capabilities, only retaining the few it needs in its
> permitted set. under normal operation it runs non-root,
> no-capabilities. temporarily raising the few capabilities it needs as
> required.

however, if one of the zebra daemons itself can re-obtain root or
elevated capabilities, an exploit can also do so. therefore, running as
non-root normally but not dropping the "right to become root" will add
an additional layer of protection, but it will not completely prevent
remote root exploits.

- ruud
--
ruud de rooij | ruud@ruud.org | http://ruud.org

thx, that's a beautiful design. i must look more into Linux capabilities.

ruud de rooij wrote:
> On Thu, 2003-08-07 at 10:51, Paul Jakma wrote:
>
>>On Thu, 7 Aug 2003 Anthony.Golia@morganstanley.com wrote:
>>
>>
>>>makes sense i'll add a user. how can it add routes to the kernel as non
>>>root though?
>>
>>because you start it up as root so that it can set things up so as to
>>allow it to temporarily change back to root for those times it needs
>>to. in normal operation it runs as something else.
>>
>>on linux, with libcap installed, it will use capabilities instead,
>>and drop all capabilities, only retaining the few it needs in its
>>permitted set. under normal operation it runs non-root,
>>no-capabilities. temporarily raising the few capabilities it needs as
>>required.
>
>
> however, if one of the zebra daemons itself can re-obtain root or
> elevated capabilities, an exploit can also do so. therefore, running as
> non-root normally but not dropping the "right to become root" will add
> an additional layer of protection, but it will not completely prevent
> remote root exploits.
>
> - ruud


--
Cheers,
Anthony

On 7 Aug 2003, ruud de rooij wrote:

> however, if one of the zebra daemons itself can re-obtain root or
> elevated capabilities, an exploit can also do so.

yes.

> therefore, running as non-root normally but not dropping the "right
> to become root" will add an additional layer of protection, but it
> will not completely prevent remote root exploits.

absolutely.

the linux capabilities stuff is the most secure - as it retains the
fewest privileges for an attacker to try regain.

the other platforms, well an exploit can indeed raise privileges to
root again.

though, it does make it slightly more difficult for an exploit to
raise privileges and actually still exploit the code further though.
on systems with non-executable stacks exploiting zebra while raising
privileges and actually doing something else becomes yet more
difficult.

NB: there is a possibility that there are exploits in the wild for
zebra. (no idea whether it is true, and if so, which versions and
whether it applies to quagga too).

> - ruud

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
No directory.

On Thu, 7 Aug 2003 Anthony.Golia@morganstanley.com wrote:

> privs_init: could not lookup user zebra
>
> can it be configed to just run as root?
>
>

Now, why on earth would you want to throw away the nice security features
that running as something OTHER than root provide? While there have not -
to date - been any security flaws related to Zebra/Quagga, that doesn't
mean that there isn't something that has not been found.


--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |

On Thu, 7 Aug 2003 Anthony.Golia@morganstanley.com wrote:

> thx, i should've seen that. believe it or not, it's easier for me to
> just run it as root than create a new user. what's the down side to
> running it as root?
>

If, for some reason, someone is able to get Zebra/Quagga to crush in a
specific way, they could potentially end up with root privs on your
box. They're going to get the privs of the program they crush.

What is so hard about typing "adduser zebra"?

--
John Fraizer | High-Security Datacenter Services |
President | Dedicated circuits 64k - 155M OC3 |
EnterZone, Inc | Virtual, Dedicated, Colocation |
http://www.enterzone.net/ | Network Consulting Services |