I'm not sure what you mean by AT&T deploying secure routers. Do you mean routers as in the devices at the core of their networks? Or as in the customer prem devices? What's the role of sandboxing for either of those devices?
Two challenges with this least-privilege strategy for software security:
1. For single-function devices, like a customer prem device for a cable network, there may not be meaningful privilege boundaries to exploit.
2. As privilege models get more complicated, the risk that privileges may accidentally equate to each other increases. This was an observation Bernstein made of his qmail security model in his retrospective paper.
1. Secure, automatic update process that keeps user config where possible.
2. Default configuration that's as secure as factory setting can get plus without unnecessary services running.
3. Running on a self-healing microkernel if possible.
4. Code for key functionality written in languages like Ada, SPARK, and/or Rust for reduced 0-days.
5. Embedded firewall with rate limiting from host network in event ISP detects DDOS.
6. Optionally, more secure way to connect to admin interface comes with installation CD or software.
Those seem like nice baseline for router that would increase its security and availibility at relatively, low cost. There used to even be a vendor selling switches and routers with INTEGRITY-178 separation kernel enforcing POLA down to the ports. Rockwell uses AAMP7G CPU to enforce it down to the thread or process level with mathematical proof of its correctness. So room to improve further to high-assurance for that end of the market, too, on top of what my list already gives.
EDIT to add what just showed up in another feed. Case in point about how much better baseline could be with small effort.
It's still a lot of effort for a manufacturer that has to constantly work on new devices to keep competing. It seems that cheap update process for this requires a microkernel based OS, which linux isn't, otherwise merging linux support for old devices is not economically viable and neither is upstreaming it. I think there was a discussion about this in a recent thread. Then there is a thing about hiring pools, we just don't have a lot of Ada, SPARK, Rust programmers in the world, which also makes the idea too expensive. DDoS, on the other hand, is not a real issue, ISPs already have the expertise and the infrastructure to deal with them, once it's going to cause too much problems for the quality of their service. I've witnessed this myself.
All kinds of embedded devices have updates without microkernels. It's more of the ability to restrict and/or write to flash in various contexts. Far as manufacturers, there's been many to offer secure servers (eg web, DNS), routers (eg GENUA on OpenBSD), firewalls (Sentinel on INTEGRITY), mainframes (Burroughs MCP), fault-tolerant (NonStop, 1802), safer CPU's (eg Java processors), and so on. It kept showing up so long as there was potential demand plus some company willing to put forth effort. Simplest is a few engineers with a background in INFOSEC & networking just making a networking products while doing what they can on sane, base features and security updates. Would go a long way. Meanwhile, separation kernel vendors of products like INTEGRITY-178B or Lynx license RTOS + communication stacks for things like routers starting around $50,000 for OEM license with Linux VM's for stuff. The big companies cranking out tens of millions of dollars in insecure routers could definitely afford that. It's just apathy. ;)
"we just don't have a lot of Ada, SPARK, Rust programmers in the world"
Sounds bright until one remembers almost every significant market in this space is an oligopoly where there's only a handful of companies. Profitable, too. They could split all the Ada, SPARK, Rust, etc programmers while still making plenty of money and getting results. Worked for companies using Ocaml (eg Jane Street), Haskell, and even Prolog. Those sorts find they get better talent when they ask for uncommon, tougher stuff.
"ISPs already have the expertise and the infrastructure to deal with them, once it's going to cause too much problems for the quality of their service. I've witnessed this myself."
Didn't stop most DDOS's from doing their damage at all. Took many players working together. Recent one had a mitigation vendor straight-up dump Brian Krebs. The problem being as easy as you describe wouldn't have such results. It's either hard or they don't care so much.
I don't want to argue, but I don't think those assumptions are correct and even if some are extrapolating them on manufacturers of consumer devices is still wrong. And this is important, because not understanding their view of the world is not going to give us any ideas of how to improve security.
I get not wanting to argue. How about instead you give me links explaining "their view of the world" with its principles, challenges, and/or tradeoffs. Even if I disagree, I might learn something about another sector of the market that I can tailor recommendations or solutions to.
I meant secure routers on customer premises, ones that are resistant to attacks from at least the network side. That was the big problem with the latest round of DDOS attacks.
What would you sandbox in a consumer router? If there's a web server in there, it needs very limited access the rest of the router.
The web server in a consumer router exists mostly for the purpose of providing an admin interface --- in fact, most attacks on customer prem devices target that web server. Many of the admin functions on the router are game-over for security.
It's a good example of something that seems like it should be straightforward to sandbox, but isn't.
Two challenges with this least-privilege strategy for software security:
1. For single-function devices, like a customer prem device for a cable network, there may not be meaningful privilege boundaries to exploit.
2. As privilege models get more complicated, the risk that privileges may accidentally equate to each other increases. This was an observation Bernstein made of his qmail security model in his retrospective paper.