Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory-safe sudo to become the default in Ubuntu

trifectatech.org

Post reply on HN
Print view View original

271–280 of 282 posts

Re: Memory-safe sudo to become the default in Ubuntu

#271

Post by aaravchen »

nottorp wrote: post #155
bArray wrote: post #121

> This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. Sudo-rs is developed by the Trifecta Tech Foundation (TTF), a nonprofit organization that creates secure, open source building blocks for infrastructure software. Ubuntu continuously updates itself without permission, killing apps and losing previous state. You have the Javascript based Gnome…

I have the hardware for a new home server waiting to be set up (as in, I don't need a new home server i'm just messing around, so once in a while i log in and configure one more service). I tried the latest Ubuntu and it seems to be targeted at either containers or desktops. Everything I wanted to set up networking wise was a pain for my little non standard configuration. Ended up wiping it and installing Debian inst…

After years of working with Ubuntu on desktops and servers, I can tell you that for a server Ubuntu will probably always be the wrong choice.

Ubuntu seems to find it necessary to always invent some new way of doing a standard thing. Like how they use netplan for networking, a tool they invented themselves for a task that already has industry standard options available, is missing basic features those alternatives have, and adds nothing the alternatives don't also have (including any better usability). They do this all the time, and have to eventually be dragged into the modern era when they finally get sick of having no community support for their one-off inferior tool.

In particular I'm just waiting for snaps to finally die. But at least that has some technical possibilities the alternatives don't, they just aren't functionally available in snaps yet. In another 20 years, if Ubuntu keeps at it with their unconfigurable, hardcoded, private snap registry and slow limited advancement snap portals-equivalent implementation, they might even have half as much functionality and packaged tools as Flatpak current has today.

---

If you want a decent server, Debian is a better option, even though they have some finnicky choices, and its enough like Ubuntu you might have some cross-ober familiarity. Some of the old standbys like Fedora aren't good options because of their frequent update schedule and lack of long term support, but there are also some very good niche options if you can dig a lot more.

Also worth noting: if you want to keep the server working, you should plan on pretty much everything being in containers. It adds some complexity to what you're doing, but keeps each little experiment isolated from the others and avoids polluting the global system.

Re: Memory-safe sudo to become the default in Ubuntu

#272

Post by ptsneves »

rlpb wrote: post #247
ptsneves wrote: post #239

Earlier quoted context omitted.

> It does default to installing security updates automatically. However, this is completely configurable. Man, but have you personally tried to disable it? Did you stop apt-daily.service apt-daily.time apt-daily-upgrade.service and apt-daily.timer? Did you repeat the same but masking and disabling those services. Don't forget to repeat that for unatended-upgrades.service. Even after that whenever our CI fails an apt-…

> Man, but have you personally tried to disable it? Sure. It's just a one line change in the configuration file (/etc/apt/apt.conf.d/50unattended-upgrades). Or, if you're doing a mass deployment, just don't install the unattended-upgrades package. > figure out what other dark pattern canonical came up with The mechanism is inherited from Debian. It isn't Canonical's architecture. If you want to hack internals to do t…

> Sure. It's just a one line change in the configuration file (/etc/apt/apt.conf.d/50unattended-upgrades). Or, if you're doing a mass deployment, just don't install the unattended-upgrades package.

That answer shows you have not seen that pattern fail.When that fails or is overwritten by an update, remember my comment.

Ironically you just added another way to configure a simple thing, proving my point.

Re: Memory-safe sudo to become the default in Ubuntu

#273

Post by lupusreal »

charcircuit wrote: post #175
lupusreal wrote: post #102

Earlier quoted context omitted.

We have that, it's called android. Anybody who finds themselves using sudo is already well off the beaten path, by their own choice. There's nothing wrong with that.

Doing system updates is not off the beaten path.

Using GNU/Linux at all is. Choosing to use such an operating system and then also choosing to do your updates from a terminal emulator is even further off the beaten path.

The beaten path is the defaults. Windows and MacOS particularly.

Re: Memory-safe sudo to become the default in Ubuntu

#274

Post by fweimer »

Vilian wrote: post #251
fweimer wrote: post #57

Earlier quoted context omitted.

You might not have a systemd instance inside a container, but you still might want to switch user IDs there.

Podman has systemd inside, you can run0 in it

Surely that depends on the container? Podman doesn't artificially inject a systemd process as PID 1 by default.

Re: Memory-safe sudo to become the default in Ubuntu

#275

Post by rurban »

theamk wrote: post #172
rurban wrote: post #114

Earlier quoted context omitted.

Capabilities. Proper microkernels already do that

how do they solve sudo's problems though? Exchanging "sudo" with "require-root-capability" or "start-privileged-session" will still have many of the same logic problems. Unless you mean something like "capabilities are always inherited, and there is no way to increase them", which would mean that sudo-like scripts are impossible, and you need to start all-new session as root user for admin actions. Good news, it's al…

fine grained.

there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages.

even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services. but capabilities only allow certain calls at certain times. there's no setuid 0, only cap this and cap that for this admin user for a certain time range.

BTW, SElinux is the default on a proper linux like Redhat. I use it daily. I also have to adjust the ssh caps, not just the firewall settings. Everybody wants that, just not the debian nobs.

Re: Memory-safe sudo to become the default in Ubuntu

#276

Post by vacuity »

rurban wrote: post #275
theamk wrote: post #172

Earlier quoted context omitted.

how do they solve sudo's problems though? Exchanging "sudo" with "require-root-capability" or "start-privileged-session" will still have many of the same logic problems. Unless you mean something like "capabilities are always inherited, and there is no way to increase them", which would mean that sudo-like scripts are impossible, and you need to start all-new session as root user for admin actions. Good news, it's al…

fine grained. there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages. even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services. but capabilities only allow certain calls at certain times. there's no setuid 0, only…

There is omitted detail here. Capabilities are a great way to determine access control (IMO, they are essential in general as a user-facing model too). However, that still leaves the question of who gets what capabilities. For the network service to be able to hand out network capabilities, it itself must have at least as much authority, and it had to get that authority from some other source of capabilities. There must be some privileged component that forges all capabilities, and actually distributes enough authority to make the system usable. For example, as soon as a human user becomes relevant, the system's user-avatar must be able to command authority, in a way that may seem sweeping. This could mean directly or indirectly changing which program is the network service, which means the ability to influence all networking activities, which is no small authority.

An agent logically has all the capabilities necessary to do what the agent should be able to do. The sum of capabilities of an agent indicates "the worst that can happen" if the agent is malicious. It makes sense that if a network service is malicious, all networking activities can be subverted. Still, the storage activities shouldn't be subverted, and of course the network service wouldn't have the storage service capability. However, if a user is malicious, anything could go wrong that the user is normally trusted to not make go wrong. Correspondingly, the user must have an expansive sum of capabilities.

Capabilities are themselves simple, but that is the mechanism perspective. Access control policy is an entirely different beast, and any mechanism at best minimizes the risks.

Re: Memory-safe sudo to become the default in Ubuntu

#277

Post by theamk »

rurban wrote: post #275
theamk wrote: post #172

Earlier quoted context omitted.

how do they solve sudo's problems though? Exchanging "sudo" with "require-root-capability" or "start-privileged-session" will still have many of the same logic problems. Unless you mean something like "capabilities are always inherited, and there is no way to increase them", which would mean that sudo-like scripts are impossible, and you need to start all-new session as root user for admin actions. Good news, it's al…

fine grained. there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages. even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services. but capabilities only allow certain calls at certain times. there's no setuid 0, only…

This all sounds very reasonable as long as servers/services are involved. Linux has capabilities for this purpose, and systemd goes a long way towards the vision you describe - daemons which do not need root and instead get all capabilities from the supervisore process.

However, were were talking about "sudo" and this is purely interactive tool (I am sure some people run sudo non-interactively, but we can all agree it's a bad security practice). So, how does this nice capabilities vision mesh with the idea of "administrator user"?

From what I see, it's not much different. Instead of "sudo" which verifies user identity+permissions and then gives out "root" or some other user, we have some other hypothetical tool ("become-admin"?) which verifies user identity+permission and gives out powerful system-changing capabilities. Frankly, I don't see much difference - it's the same security model either way.

(A related argument I've seen is "you should not need sudo for common tasks like update software or configure network" - but on modern Linuxes, you don't need sudo for that already, this is done via dbus + polkit calls. No "proper microkernels" required, that is already deployed everywhere.)

Re: Memory-safe sudo to become the default in Ubuntu

#278

Post by rlpb »

bArray wrote: post #261
rlpb wrote: post #248

Earlier quoted context omitted.

> A better default behaviour would be to alert the user and allow them to choose to indefinitely defer by "accepting the risk". That would be terrible UX and is exactly contrary to Ubuntu's philosophy, which is to do the right thing by default. The alternative is to bombard the user with questions that they're generally not in a position to understand, and force them to receive an education on stuff that doesn't matt…

> That would be terrible UX and is exactly contrary to Ubuntu's philosophy, which is to do the right thing by default. Even in Windows (or at least it used to be), the decision to perform an update now was a user decision. Just killing off applications without warning is the worst UX ever. Randomly killing stuff off is the opposite of what I want my OS doing. > The alternative is to bombard the user with questions th…

> I saw an Ubuntu user's system restart their snap programs in the middle of delivering a conference presentation without warning.

It's been years since they added warnings for upcoming snap updates. There's also "refresh awareness", which defers updates (to a limit, with warnings before exceeding the limit) while a user is using an app.

Re: Memory-safe sudo to become the default in Ubuntu

#279

Post by rlpb »

aaravchen wrote: post #270
rlpb wrote: post #182

Earlier quoted context omitted.

> My team's current favorite is the upgrade process itself suddenly having new interactive prompts breaking our scripts. This is how dpkg and apt have worked in Debian and Ubuntu pretty much since their inception. Look into debconf, dpkg and ucf configuration to learn how to integrate these with your automation. The mechanisms for this have existed for decades now and have not substantially changed in that time.

dpkg grew knowledge of Source lists suddenly? If you're installing software from Debian/Ubuntu repos, you can only use aptitude or apt to my knowledge. Other tools give you the ability to install DEB files you already have, and manage what's on your system currently. And aptitude and apt are both well known for never having had a "stable" scriptable interface. In fact they themselves tell you that their commands are…

Your understanding is just outright wrong. The `apt` command has an unstable interface so that it can improve the CLI without worrying about breaking scripts. The `apt-get` command is the stable interface for scripts. `apt` was created after `apt-get` became ossified exactly because the developers work hard to keep the interface for scripts stable.

> In fact they themselves tell you that their commands are not stable and should not be used for scripting, despite no alternative mode or application existing.

No, that's just the apt command, not the apt-get command, and the manpage for apt tells you exactly how to do this instead. It's clearly documented, so your "despite no alternative mode or application existing" claim is simply ignorant.

Please read the documentation and learn how to use the tooling before criticizing it and misleading others with claims that are outright wrong.

Re: Memory-safe sudo to become the default in Ubuntu

#280

Post by vacuity »

theamk wrote: post #277
rurban wrote: post #275

Earlier quoted context omitted.

fine grained. there's no god-mode who can do everything. there's no universal kernel level. micro means only minimal things happen in the kernel or at root level, like routing messages. even windows understood that those times, when they did split Administrator from System. linux followed then with system users for certain services. but capabilities only allow certain calls at certain times. there's no setuid 0, only…

This all sounds very reasonable as long as servers/services are involved. Linux has capabilities for this purpose, and systemd goes a long way towards the vision you describe - daemons which do not need root and instead get all capabilities from the supervisore process. However, were were talking about "sudo" and this is purely interactive tool (I am sure some people run sudo non-interactively, but we can all agree i…

I was also the one who wrote a sibling comment saying that capabilities aren't magical, but I do think they are excellent as far as any mechanism goes. Linux doesn't nearly go far enough in capability-based security, and merely adapting practices fails to make full use of capabilities. It's a bug if I have to verify my identity often for a routine task, whether it's through sudo or polkit. User friction is bad for security in many ways. Instead, configure the service once to have the capabilities you would give it each time anyways. Take it out of the user's hands and set it down on the desk (still in their control, just not taking up space). polkit is not quite there, whereas capabilities easily confine all programs (don't have to support polkit), are trivially flexible in behavior while being both secure and invisible by default, and provide control to the proper agents (users and involved programs). Capabilities turn access control from a hard problem plus various pitfalls to just a hard problem. Rather than an incrementally better solution, changing paradigms here is a good idea. Although Unix already most has capabilities through file descriptors, so in some sense its "everything is a file" philosophy can't go far enough.
Post reply on HN