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: https://github.com/cdeccio/cougarnet 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
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,
On Jul 14, 2022, at 17:01, Casey Deccio <casey@deccio.net> wrote:
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:
https://github.com/cdeccio/cougarnet
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
-- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Jul 15, 2022, at 8:25 AM, J. Hellenthal <jhellenthal@dataix.net> wrote:
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.
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
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. :) On Fri, Jul 15, 2022 at 11:09 AM Casey Deccio <casey@deccio.net> wrote:
On Jul 15, 2022, at 8:25 AM, J. Hellenthal <jhellenthal@dataix.net> wrote:
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.
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
On Jul 15, 2022, at 9:07 AM, Casey Deccio <casey@deccio.net> wrote:
On Jul 15, 2022, at 8:25 AM, J. Hellenthal <jhellenthal@dataix.net> wrote:
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.
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.
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
On Fri, 15 Jul 2022 at 17:29, J. Hellenthal via NANOG <nanog@nanog.org> wrote:
"%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.
May I request information substantiating the risk. As far as I see, infosec is largely horoscopes for IT people. -- ++ytti
On 7/15/22 11:18 AM, Saku Ytti wrote:
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. -- Grant. . . . unix || die
On Fri, 15 Jul 2022 at 21:57, Grant Taylor via NANOG <nanog@nanog.org> wrote:
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. -- ++ytti
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? On Sat, Jul 16, 2022 at 3:04 AM Saku Ytti <saku@ytti.fi> wrote:
On Fri, 15 Jul 2022 at 21:57, Grant Taylor via NANOG <nanog@nanog.org> wrote:
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.
-- ++ytti
On Mon, 18 Jul 2022 at 18:48, Tom Beecher <beecher@beecher.cc> wrote:
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?
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. -- ++ytti
participants (5)
-
Casey Deccio -
Grant Taylor -
J. Hellenthal -
Saku Ytti -
Tom Beecher