Tool for virtual networks

Mailman List Mirror (Read Only)
1

Dear colleagues,

I've been developing a tool for building and experimenting with virtual networks, primarily for use with teaching network protocols. It's an active work-in-progress, but I thought it might be time to reach out to NANOG in case anyone else might find it useful and/or might have feedback to offer. Here is the code:

It includes layer-2 switches, VLANs and trunking, and routers, all using Linux processes in their own namespaces as network "nodes". It was inspired by mininet (https://mininet.org) but it was developed from scratch to meet different needs.

The README has additional information. If you install and run the code, *please* do it in a *virtual machine*. At this point, it requires superuser capabilities to run things like "ip link", "ip addr", and "sysctl", among other things, using sudo. Much on the to-do list, but it meets my immediate needs. Just wanted to share in the mean time.

Cheers,
Casey

2

For a quick cursory overview of this project, I would urge you to add an adendum or change the following line in the installation documentation...

"%sudo ALL=(ALL:ALL) NOPASSWD: ALL"

This is technically influencing bad behavior with sudo for those that are not aware of the security impacts of such decisions.

I'm not one to provide a negative remark usually without suggesting a result that provides a positive impact that can be built upon. So with that said and along the lines of that id suggest adjusting the documentation to contain something of the sorts of a guided only per user or separate group other than "%sudo"... maybe "%cougarnet" and add instructions for creating the group and adding users to that group.

Beyond that... nice project and thank you for your contribution to networking. This may be beyond the scope of just this one mailing list and wish you the best.

Regards,

3

Thanks so much for the feedback. As noted, this is still a work-in-progress. Now that I'm mostly past the proof-of-concept phase of development, and one of my near-term to-do items is to improve least privilege in the code. I think it does fairly well in other places, but the sudo access is still too liberal. At the moment, the plan is to enumerate the commands used with sudo in the code and apply them to a group of which a user must be a part. For example:

%cougarnet ALL=(ALL:ALL) NOPASSWD: /usr/bin/ip, /usr/sbin/sysctl

But in the mean time (and generally) this should really only be used in a dedicated VM. And the *primary* audience is my networks class--even though I shared with the broader networking community, in case others might find it useful or have feedback (thank you!).

Cheers,
Casey

4

May I request information substantiating the risk.

As far as I see, infosec is largely horoscopes for IT people.

5

May I request information substantiating the risk.

Have you ever walked away from your terminal without locking it? Or seen anyone else do it?

Unless you are within Sudo's grace period (defaults to five minutes) the person at your keyboard won't be able to authenticate to sudo as you if they have to enter your password.

There are also concerns of changing effective users on systems to one that has the NOPASSWD: option, thereby enabling the original user to do what the new user could do without authenticating as the new user.

As far as I see, infosec is largely horoscopes for IT people.

I don't believe avoiding NOPASSWD: is just a horoscope.

6

Have you ever walked away from your terminal without locking it? Or
seen anyone else do it?

Probably, and probably also after I've already sudoed regardless of
authentication. And of course a retrospective look from any point to
history shows us various trivial local privilege escalation bugs which
have existed for 5-10-15-20 years, i.e. various trivial local
privilege escalation bugs exist now for anyone with hobbyist interest
finding them.
Devices which have a large commercial motive to keep safe and the
vendor owns the whole vertical and thus are easy to build securely,
are regularly owned by hobbyists just for fun. If there is a
commercial motive, you are being pwned regardless of your sudo policy.
Realised risks for big companies appear to be extremely cheap, based
on publicly disclosed issues and their impact on market
capitalization. Cost of protection must be significantly lower than
realised risk.
Attacker has massive financial leverage, I don't have context to say
anything actually useful, but I believe the leverage is easily 1k, and
could be much more than 1M. That is, every dollar my adversary spends
attacking, I must spend 1000 dollars protecting, to successfully stop
them.
We have many obvious problems in tooling, like using C, which we
pretend are user errors 'git good', which if we decided to fix, could
significantly reduce attack surface, but we don't, no one cares about
infosec.

There are also concerns of changing effective users on systems to one
that has the NOPASSWD: option, thereby enabling the original user to do
what the new user could do without authenticating as the new user.

I can accept concerns, and people are very much free to interpret
their security posture as they wish. But offering objective truths
from opinions is not appropriate.

It is very easy to paint various risk scenarios, but without
substantiating what is the cost of preventing the risk and what is the
cost of realised risk, it is just horoscope. One thing you can achieve
easily in infosec, is decreased productivity due to making things
slower or reducing motivation by forcing people to use workflow they
are not accustomed to.
This model causes escalation of dubious policies which never needed to
be substantiated. Maybe some help, maybe not, but at least they
increase cost.

Various models of working are valid, you could have root only, and you
could use ssh certificate signing for certificates which are valid for
minutes.

I don't believe avoiding NOPASSWD: is just a horoscope.

Believe being the operative word. Maybe you are right, maybe not,
presenting it as factual truth is dishonest and potentially harmful.

My general rule of thumb, satisfy legal, regulatory and customer
contract requirements for infosec and other than that, largely ignore
policies which are only justifiable by infosec. Of course in many
cases doing things the right way, happens to align with the infosec
community desires and has 0 infosec cost, while having some perceived
infosec gains, and that is fine.

7

But in the mean time (and generally) this should really only be used in a dedicated VM. And the primary audience is my networks class–even though I shared with the broader networking community, in case others might find it useful or have feedback (thank you!).

It’s a cardinal rule that anything built with a set of assumptions about the environment it operates in will inevitably be run in a different environment somewhere, someday. :slight_smile:

8

Believe being the operative word. Maybe you are right, maybe not,
presenting it as factual truth is dishonest and potentially harmful.

My general rule of thumb, satisfy legal, regulatory and customer
contract requirements for infosec and other than that, largely ignore
policies which are only justifiable by infosec. Of course in many
cases doing things the right way, happens to align with the infosec
community desires and has 0 infosec cost, while having some perceived
infosec gains, and that is fine.

Is it an accurate representation of your position here that NOT allowing any user in the sudo group access to run any command they want is somehow ‘security theater’ then?

9

I couldn’t have replied better

10

I'd rather say, if your only comment on a matter is unsolicited
infosec opinion, which you can't substantiate, there are better forums
for that. But, yes.

11

For those that care, I’ve made some changes, such that this is all that is needed in /etc/sudoers

%cougarnet ALL=(ALL:ALL) NOPASSWD:SETENV: /usr/libexec/cougarnet/syscmd_helper

https://github.com/cdeccio/cougarnet/pull/14

Cheers,
Casey