[HN Gopher] SSH as a Sudo Replacement
___________________________________________________________________
SSH as a Sudo Replacement
Author : legobeet
Score : 209 points
Date : 2024-06-22 23:14 UTC (23 hours ago)
(HTM) web link (whynothugo.nl)
(TXT) w3m dump (whynothugo.nl)
| aaaronic wrote:
| Am I missing something?
|
| How is logging into ssh (sshd) AS root more secure than using
| sudo? I honestly don't even know how dangerous that is because
| I've always been told to never allow it. I see here thought goes
| into preventing that for a remote user, so I'm not talking about
| that aspect of security here.
|
| Maybe it has to do with #3 in the sudo limitations -- I certainly
| don't see any benefits vis-a-vis #1.
|
| I totally get that this is an experiment, but I suspect it is
| more vulnerable than using sudo, not less (the open socket proxy
| looks interestingly vulnerable to a man in the middle attack).
|
| Having said all that, I did learn some tricks old tools are
| capable of, so kudos for showing me something new.
| op00to wrote:
| A big part of sudo is that you should be running individual
| commands using sudo to increase auditability rather than simply
| running sudo bash or whatever.
| aaaronic wrote:
| I can agree with that, though admit to being guilty of using
| sudo bash far more often than I should.
|
| I honestly thought they'd be using ssh that way (single
| command at a time), though I'm still not sure to what
| security end.
| mmh0000 wrote:
| If 'sudo' is properly configured running bash or anything
| that allows command execution (vim, eMacs, etc) is
| disallowed.
|
| Also, may I introduce you to the 'sudo -i' option.
| dns_snek wrote:
| > If 'sudo' is properly configured running bash or
| anything that allows command execution (vim, eMacs, etc)
| is disallowed.
|
| Keep in mind that this is borderline impossible to
| enforce unless your goal is just to stop the most common
| ways of accidentally breaking the policy. A list of
| commands that allows breaking out into a full shell
| includes: less, apt, man, nano, wget & many more.
|
| https://gtfobins.github.io/#+shell
| acka wrote:
| > eMacs
|
| This made me chuckle. Apple influencing the way Emacs is
| capitalized (pun intended) versus RMS's stance on Free
| Software couldn't be further apart I think.
| mmh0000 wrote:
| You're correct there! Wrote that up on my tiny Apple
| device and really couldn't be bothered to correct Apple's
| spellcheck. Text editing from a 5in touchscreen is very
| painful.
| op00to wrote:
| I sudo bash a lot as well. Some times I regret it when I
| try to figure out what the hell I did months ago. :)
| kiririn wrote:
| Auditd and pam_tty_audit can take care of all your auditing
| needs
| op00to wrote:
| Sure! All part of layered controls and reporting.
| dmw_ng wrote:
| It's comical to see the sudo codebase mentioned in the same
| breath as increasing auditability here
| lmz wrote:
| The sudo binary is suid root / privileged and is exposed
| directly to the untrusted user. If anything goes wrong inside
| of sudo (with the user's entire environment as the surface
| area), it may be exploited.
|
| The ssh approach does not expose a suid binary. Instead it uses
| the ssh network layer so it is no less secure than accessing
| ssh over a network, which is considered pretty secure.
| hughesjj wrote:
| ...why not just su then?
| rpgwaiter wrote:
| root would need a defined password, which opens up other
| security concerns
| akira2501 wrote:
| Even if you allow passwordless su for users in the wheel
| group?
| djbusby wrote:
| Do what!?
| bdd8f1df777b wrote:
| That's extremely dangerous. Any software running as a
| wheel user can escalate privileges willy nilly.
| immibis wrote:
| they can also access your ssh private keys
| rascul wrote:
| In theory, those ssh private keys are password protected.
|
| In practice, maybe not.
| ec109685 wrote:
| They were stored in the user's yubikeys (or similar) in
| this example.
| bogantech wrote:
| If you do that you deserve what you get
| bobmcnamara wrote:
| plzno
| CaliforniaKarl wrote:
| We've got root passwords set on, IIRC, all of our
| systems. They're long, random, and can only be entered
| through the console on the VGA port or the IPMI console.
| lmz wrote:
| su is also a suid binary, no? It is probably a lot less
| complex than sudo.
| Sparkyte wrote:
| I would assume if you has to use SSH or sudo you've already
| lost. I've been working with people where we just completely
| lock down the VM or Container. They only allow necessary flow
| of traffic and are managed entirely from golden builds. If
| you need to make changes or fix something it is a new vm or
| container.
| gunapologist99 wrote:
| This premise is incorrect: SSH doesn't need to be an suid
| binary because it's _already_ running as root, and then SSH
| creates a new environment for the user, exactly like sudo
| does, but with all the added complexity and overhead (and
| surface) of privileged network access.
|
| To be clear, I _love_ SSH and we even run a userify instance
| to distribute keys, but juts comparatively the surface area
| of the ssh daemon alone is greater than sudo alone.
|
| (however, even with the extra complexity, you might trust the
| history of portable OpenSSH more than sudo, and that's a
| good, but different, conversation to have also.)
| lmz wrote:
| But the area under control by the invoking user is data
| over one socket vs the whole calling environment e.g.
| environment vars, local files. Surely that counts for
| something.
| o11c wrote:
| I'm skeptical of the approach in the linked article, but:
|
| > I honestly don't even know how dangerous that is because I've
| always been told to never allow it.
|
| You've fallen for the FUD. In reality, logging in directly as
| root over remote SSH is strictly more secure than logging in as
| user over remote SSH and then using `sudo`.
|
| If user@home uses ssh to root@server, then root@server is only
| compromised if user@home is compromised.
|
| If user@home uses ssh to user@server then sudo to root@server,
| then root@server is compromised if _either_ user@home or
| user@server is compromised. In particular, it is fairly common
| for user@server to be running some other software such as
| daemons or cronjobs. Please don 't give out free root
| escalation (and often lateral movement due to password reuse)
| to anyone who manages to infect through those!
|
| (This of course does not apply if sudo is used in whitelisted-
| commands-only mode and does not take either passwords or
| credentials fully accessible from the remote host)
| cycomanic wrote:
| I'm not sure I agree with this argument. Sure you can say
| theoretically it's one less account that could be
| compromised, but in practice I see a bunch of caveats.
|
| 1. If we allow password based logins, there will be many
| orders of magnitude more login attempts to root than any
| other user. So if you have to allow password based logins,
| you pretty much never want to allow root login.
|
| 2. If we disallow password based logins, a user account would
| be as save as a root login, except again that the root
| account is the much more valuable target so will get much
| more attention. I also do see the relevance of cronjobs (root
| does run them as well) and naturally no user that has sudo
| privileges should be be running network exposed services.
|
| 3. In cases were admin rights have to be shared amongst
| multiple users, are you going to share the same key for all
| users (probably not a good idea) or give every user a
| separate key (making key management a bit of a nightmare,
| user management is much easier).
|
| 4. As you pointed out yourself sudo gives you much more fine-
| grained control over commands that can be run.
| kchr wrote:
| > 3. In cases were admin rights have to be shared amongst
| multiple users, are you going to share the same key for all
| users (probably not a good idea) or give every user a
| separate key (making key management a bit of a nightmare,
| user management is much easier).
|
| To solve the key management nightmare, short-lived SSH
| certificates can be used to map an identity to a shared
| user account. Hashicorp Vault is one option for issuing
| such certificates, but there are other alternatives as
| well.
|
| https://docs.redhat.com/en/documentation/red_hat_enterprise
| _....
| fsniper wrote:
| The approach is comparing - Theoretical configuration errors,
| or theoretical vulnerabilities that may or may not be there
| with - Having a new daemon running (a new attack surface) which
| - may also have configuration errors, or vulnerabilities as
| such - and also removes a few layers of user based
| authorisation with a single root level
|
| This approach is somehow considered more secure.
|
| And in a rational way, and of course for any rational security
| perspective this can't be considered more secure, just
| different.
| irusensei wrote:
| > How is logging into ssh (sshd) AS root more secure than using
| sudo?
|
| Article describes an additional SSH server listening on an Unix
| socket. The usual threat model about exposing root logins from
| the internet may not apply here.
| joveian wrote:
| The big advantage is if setuid and setgid support can be
| entirely removed. There are a bunch of special cases that have
| been added over the years to try to deal but increasing
| priviledges of a process is fundamentally more challenging in
| the unix security model than only ever lowering priviledges. Of
| course these days Linux has priviledge escalation via user
| namespaces as well.
| jeffhuys wrote:
| Psst... privilege has no letter D
| iroddis wrote:
| I think it's a bit remiss to not include all of the downsides of
| this approach. sudo allows control over which groups can exercise
| which commands, what args those commands accept, subshell spawns,
| etc, etc, etc.
|
| This approach loses a lot of this fine-grained control, and also
| relies on trusted keys, which are harder to manage than editing a
| sudoers file.
|
| To see all the amazing things that sudo can do, I'd really
| recommend the Sudo Mastery book.
| yjftsjthsd-h wrote:
| SSH can do some of that with ForceCommand, though I agree
| that's not as flexible/precise.
| hernantz wrote:
| This is a similar idea to run0 by Systemd:
| https://news.itsfoss.com/systemd-run0/
| ape4 wrote:
| And run0 isn't roll-your-own. Its audited and probably better
| than home grown.
| mise_en_place wrote:
| This is an elegant solution to the problem. We don't need to
| treat users as children, but at the same time we should avoid
| potential foot guns with sensible defaults. I'd argue that even
| `su` is not needed, if you need to be root, then login as root
| via console. This is as close as possible to logging into root
| from the console tty.
| bogantech wrote:
| > if you need to be root, then login as root via console
|
| 1: This requires every user to have the root password, while
| sudo does not
|
| 2: If everyone just logs in as root there's no way to audit who
| actually logged in and did what.
| kchr wrote:
| Additionally, you need to rotate and distribute the new root
| password to all root users when you want to remove access for
| someone.
| joveian wrote:
| You can have multiple accounts with uid/gid 0 (and can set up
| smart card or u2f login too if you want).
| xfitm3 wrote:
| Fixing things that aren't broken. Changing things just because
| they can be changed. Sometimes boring and stagnant is good.
| irusensei wrote:
| I wouldn't go as far to say sudo is broken but have you
| considered why would people create things such as doas and run0
| if sudo is good enough?
| cycomanic wrote:
| So what happens if ssh (IIRC correctly in typical configurations
| it depends on network to start) fails to start at boot? You can't
| even login at failsave console. What does this actually buy us
| over sudo or su? Sure you avoid a setuid binary but instead you
| are now running a network service (even though only connected to
| a socket) with root priveledges.
| jethro_tell wrote:
| As far as I'm concerned, I use setuid/sudo for auditing. At
| this point, I don't really do multi-user/multi service boxes.
| Almost everything I have that's multi-tenant at this point is
| k8s and you can just use kubectl endpoint instead of ssh. But
| if you're allowed to log in, you're allowed to setuid to root.
| So for a k8s box, that's the platform infra team and access to
| the services on top is through the k8s permissions provider.
|
| For the platform infra teams, if you just need something like
| metrics and logs, that's already off box. If you need to
| trigger some job or workflow, you can use the pipeline.
|
| But when someone does log in and do root stuff, I want to have
| an audit log.
|
| I actually can't think of a single box I own where someone with
| a login doesn't also have root for everything.
|
| Obviously, I understand the services doing setuid thing, but in
| the case of services, you generally have systemd doing setuid
| to drop permissions instead of the other way around.
| CaliforniaKarl wrote:
| > You can't even login at failsave console.
|
| Linux consoles (the ttys that appear over local display or
| remote-access KVM, or the ttyS* devices that appear over serial
| ports and IPMI SoL) do not use sudo or su. Those consoles use a
| program like `getty`, or a window-manager; all those programs
| are non-suid programs that are started as root.
|
| Your system should have a root password set, for logins via
| console.
| TacticalCoder wrote:
| > Your system should have a root password set, for logins via
| console.
|
| TFA says that he's prefixing his password hash with '!',
| making login with a root password impossible (including at
| the console).
|
| Hence GP's question.
| TacticalCoder wrote:
| As I run a system similar to the one used in TFA I'll give my
| take...
|
| > So what happens if ssh (IIRC correctly in typical
| configurations it depends on network to start) fails to start
| at boot?
|
| I do this for my main desktop. If the worse of the worse
| happen, I've got backup of everything (we all do right?) and I
| re-install the system.
|
| What I mean is: what do you do when you SSD is dead? You can't
| even login at failsafe console either.
|
| In 30 years of using Linux I've have hard disk die on me _way_
| more than I had my _sshd_ daemon not starting. The ratio is
| even a divide-by-zero error.
|
| Arguably if my OS had its sshd daemon randomly not starting,
| it'd be an indication to me that it's time to move to a more
| stable OS.
|
| > What does this actually buy us over sudo or su?
|
| Much harder to pull local privilege escalation exploits.
| alexey-salmin wrote:
| > Much harder to pull local privilege escalation exploits.
|
| That's not certain. sshd is way bigger than sudo, so chances
| of it having an exploitable bug seem higher.
| gizmo686 wrote:
| If you have access to the bootloadet, you can still set
| systems.unit=emergency.target, or init=/bin/bash, or
| rd.break=pre-pivot, or boot into a live-cd environment. All of
| the normal emergency options work.
|
| For less fatal emergencies, I don't see anything that would tie
| this instance of sshd to tge network.
| TacticalCoder wrote:
| 100 000 times yes: I do something similar and I described that
| here on HN in a comment / comments in the past!
|
| The way I do is a bit different...
|
| I'm using a dedicated machine as my physical "SSH console" and
| that machine is living on a private LAN which is separated from
| the rest of the machines at home. It's on an unmanaged switch,
| using ethernet cables (but no trunk).
|
| Then the only way to login is using SSH but, here's a little
| spin... _with a Yubikey_.
|
| The desktop PC has its own firewall, only accepting SSH traffic
| in from the IP / MAC address of my "SSH console" (on the private
| LAN it's sharing with the SSH console... On the other physical
| LAN, my desktop can access the Internet).
|
| Then the _sshd_ daemon is configured to only allow pub /priv key
| logins, no password logins.
|
| So basically when I need root, I boot up my "SSH console" (which
| boots ultra quickly for there's basically nothing on that
| machine), log in, hit the up arrow to get back the "ssh root@..."
| line, hit enter, press the Yubikey.
|
| That "ssh console" and its keyboard is on my desk, always withing
| reaching distance.
|
| iptables/nftables (on a private LAN moreover, physically
| separated from the other private LAN) + sshd: you judge if this
| is more or less secure than sudo binaries / su.
|
| As to the "why", I'd answer "because I can". I did set that up
| such a long time ago that I don't even remember when I did. I
| think I started toying with that idea two years ago and I've been
| using it ever since. Zero problem. Not a single issue.
| r4indeer wrote:
| Sounds like what you have is similar to the idea of a bastion
| host, even if not quite the same.
| kelnos wrote:
| My main objection to this is just the added complexity. Instead
| of a single suid binary that reads a config file and calls
| exec(), now you have one binary that runs as root and listens on
| a UNIX socket, and another that talks to a UNIX socket; both of
| them have to do asymmetric crypto stuff.
|
| It seems like the main argument against sudo/doas being presented
| is that you have a suid binary accessible to any user, and if
| there's a bug in it, an unauthorized user might be able to use it
| for privilege escalation. If that's really the main issue, then
| you can: chgrp wheel /usr/bin/sudo
| chmod o-rwx /usr/bin/sudo
|
| Add any sudoers to the wheel group, and there you go: only users
| that can sudo are allowed to even read the bytes of the file off
| disk, let alone execute them. This essentially gives you the same
| access-related security as the sshd approach (the UNIX socket
| there is set up to be only accessible to users in wheel), with
| much much much less complexity.
|
| And since the sshd approach doesn't allow you to restrict root
| access to only certain commands (like sudo does), even if there
| is a bug in sudo that allows a user to bypass the command
| restrictions, that still gives no more access than the sshd
| approach.
|
| If you are worried about your system package manager messing up
| the permissions on /usr/bin/sudo, you can put something in cron
| to fix them up that runs every hour or whatever you're
| comfortable with. Or you can uninstall sudo entirely, and
| manually install it from source to some other location. Then you
| have to maintain and upgrade it, manually, of course,
| unfortunately.
| alexey-salmin wrote:
| > Add any sudoers to the wheel group, and there you go: only
| users that can sudo are allowed to even read the bytes of the
| file off disk, let alone execute them.
|
| That's very sensible, I wonder why it's not the default setup
| everywhere.
| cqqxo4zV46cp wrote:
| It's at the very least incompatible with *some^ hypothetical
| sudo configurations. It's probably a good hardening practice
| if you know how sudo is going to set up on the machine.
| rascul wrote:
| I've seen a wheel or sudo group often enough to think it's
| common.
| dingensundso wrote:
| Having a wheel group that is allowed to run any command with
| su rights is the default setup, but it's not the only one.
|
| I have used sudo a lot of times to allow a specific user to
| run exactly one command with elevated rights. In those cases
| they weren't in the wheel group.
| riedel wrote:
| Actually retristricting defined commands to defined sudoers
| should be one of the main use cases of sudo. This could be
| done as well via ssh config but one would need a lot of
| keys if you don not want a wrapper (and rewrite sudo all
| over)
|
| If you are really thinking security, elevating a standard
| user seems bad practice to anyways. It is rather I guess a
| way to protect the user to do `rm -rf /` accidentally. On
| the other end adding an another layer of obscurity is
| practically adding a bit of security against script
| kiddies. But if that is of concern one could also rename
| the sudo binary.
|
| One last thing the SSH trick might be interesting is the
| portability but in this case I would rather go via a
| standard TCP socket.
| jkhanlar wrote:
| Has anyone prepared a list of distributions indicating the
| default sudo setup comparing to each other? I'd be interested
| to see the defaults for each distro as a factor to consider.
| kelnos wrote:
| Probably because there's nothing that says only users in
| wheel (assuming your OS/distro even has that group; some
| don't) can sudo. You can grant any user with any group
| membership access to sudo, either full access, or restricted
| to only certain commands.
|
| If the package was set up to install /usr/bin/sudo so it was
| only runnable by members of the wheel group, that wouldn't
| work.
| kmeisthax wrote:
| It's worth noting that the reason why your OS/distro
| doesn't have or doesn't respect wheel is largely down to
| RMS opposing it[0], instead favoring people trading the
| root password around to unauthorized users.
|
| [0] https://web.archive.org/web/20070603191229/http://www.g
| nu.or...
| sham1 wrote:
| It's also worth noting that the Coreutils `su` is no
| longer in use by anyone, and that the `su` from the
| shadow-package absolutely checks for wheel. It's even
| configurable if you haven't enabled PAM by configuring
| `SU_WHEEL_ONLY` in your login.defs. And with PAM you
| configure that via PAM.
|
| Hell, not even GNU distros like GNU Guix, Parabola, nor
| Trisquel follow RMS' opinions on this anymore.
| ilius2 wrote:
| Not all distros use `alias su='sudo -i'`. Ubuntu does.
| Debian does not. Not sure about others.
| peanut-walrus wrote:
| Not every user who uses sudo is admin or elevates to root.
| lttlrck wrote:
| Maybe also make /usr/bin/sudo immutable? would that help
| prevent a package manager from messing with it? I think so.
| ec109685 wrote:
| How would you do that?
| xomodo wrote:
| man chattr
| vrotaru wrote:
| lsattr - for reading attributes chattr - for setting them
|
| You need the `i` attribute. But this is filesystem
| dependent. Anyway protecting the `sudo` binary from package
| managers is a so-so idea.
| kelnos wrote:
| The downside of this is that if you have your system set up
| to automatically install package updates, then it will start
| failing, which might kill _all_ automatic updates.
|
| On Debian, for example, I have unattended-upgrades set up to
| automatically install security updates. sudo is reasonably
| likely to have updates for security reasons.
| dpifke wrote:
| There are multiple ways to "override" a file managed by
| dpkg:
|
| https://wiki.debian.org/DebianAlternatives
|
| https://www.debian.org/doc/debian-policy/ap-pkg-
| diversions.h...
| guerby wrote:
| Except when physically logged in via console you're already
| using ssh before using sudo.
|
| So the complexity you describe is already there.
|
| sudo removed is one less moving part in the end.
| inopinatus wrote:
| That is a furphy, because both tools are also used non-
| interactively.
|
| If you forced me to choose one to remove, I'd delete ssh in
| many cases. Anything production that isn't bare-metal is a
| candidate for never allowing a remote terminal. Easiest with
| cloud instances since they're almost completely disposable,
| but many sites still don't have the stomach/discipline for
| it.
| krispyfi wrote:
| TIL: "furphy" https://en.m.wikipedia.org/wiki/Furphy
| kelnos wrote:
| I don't see how _two_ sshd daemons and two sessions is less
| complicated.
|
| Yes, removing sudo is one fewer moving part, but sshd is a
| much larger moving part than sudo. (If you think sudo is a
| larger moving part than it should be, I'd agree, and you can
| use doas instead.)
|
| Regardless, the vast majority of my sudo usage is on my local
| machine, so there's no sshd involved at all.
| euroderf wrote:
| Pardon my ignorance, but I have to ask for explanation of what
| the wheel group is and does. I'm aware that this might open a
| can of worms.
| ffsm8 wrote:
| The wheel group is just a regular user group, its just the
| name Debian gives the group with admin permissions.
|
| It's no different to any other user group on linux systems
| and you could replace the name wheel with admin, freethinker,
| systemdestroyer or whatever else you wanna call it.
| bozey07 wrote:
| Not really! In modern Linux specifically it's just a regular
| user group, but it's the de-facto standard name of the
| "administrator" group - users who can escalate to root
| privileges.
|
| You might not even have wheel anymore; Debian just calls it
| "sudo" now.
| kqr wrote:
| In addition to being the default name for the admin group in
| Debian, the name has some history:
|
| > [from slang 'big wheel' for a powerful person] A person who
| has an active wheel bit. "We need to find a wheel to unwedge
| the hung tape drives." The traditional name of security group
| zero in BSD (to which the major system-internal users like
| root belong) is 'wheel'.
|
| > The term was invented on the TENEX operating system, and
| carried over to TOPS-20, XEROX-IFS, and others. The state of
| being in a privileged logon is sometimes called wheel mode.
| This term entered the Unix culture from TWENEX in the
| mid-1980s and has been gaining popularity there (esp. at
| university sites).
|
| http://www.catb.org/~esr/jargon/html/W/wheel.html
| WD-42 wrote:
| Great bit of history, thanks!
| blueflow wrote:
| > And since the sshd approach doesn't allow you to restrict
| root access to only certain commands [...]
|
| The ForcedCommand infrastructure.
| flakes wrote:
| There's also a command argument that can be provided in the
| authorized keys setup, which can force connections with a
| particular key to hit an entry-point application.
| blueflow wrote:
| This is the ForcedCommand mechanism.
| tankenmate wrote:
| Personally I use etckeeper[0] to make sure all changes to /etc
| are tracked, either by software installs / upgrades, or done by
| humans. It's also great when needing to upgrade a machine to a
| newer release as you can create a patch file with all your
| local changes and apply that patch to a clean install and do a
| three way merge that will highlight all conflicts and keep you
| up to date and any changes required from one release to the
| next without having to research everything just in case.
|
| [0] https://etckeeper.branchable.com/
| spydum wrote:
| such a great idea, i have not seen this before. back in my
| solaris admin days, we used to keep config stuff version
| controlled locally like this with rcs; found it super useful
| for quickly answering "what changed, and how" during
| incidents (whereas just looking for modified files and
| fetching backups was a slow ordeal)
| kstrauser wrote:
| I like Chezmoi for this, and also use it to manage my home
| directory.
|
| Plain ol' git is also nice in a pinch.
| mschuster91 wrote:
| Honestly I prefer running Ansible for that. Once you have a
| boilerplate set up the overhead is minimal and you don't have
| to fight each specific program's config file syntax just to
| figure out how to do comments.
| vbezhenar wrote:
| If you could configure your linux kernel without suid support,
| that would be huge benefit for security, IMO. suid feature is
| huge security hole.
|
| Whether fighting one particular suid binary worth it, is
| questionable indeed. But this is good direction. Another modern
| approach to this problem is run0 from systemd.
| westurner wrote:
| "List of Unix binaries that can be used to bypass local
| security restrictions" (2023)
| https://news.ycombinator.com/item?id=36637980
|
| "Fedora 40 Plans To Unify /usr/bin and /usr/sbin" (2024)
| https://news.ycombinator.com/item?id=38757975 ; a find
| expression to locate files with the setuid and setgid bits,
| setcap,
|
| man run0: https://www.freedesktop.org/software/systemd/man/de
| vel/run0....
| arp242 wrote:
| > IMO. suid feature is huge security hole.
|
| As opposed to running background processes as root...?
|
| This is just mindless dogma at this point. You're going to
| need _something_ to elevate permissions, and setuid is as
| good of a scheme as any. ssh or run0 are not magic and just
| as "vulnerable" as setuid or anything else. Any of these
| schemes are "security holes" if you abuse it.
| herczegzsolt wrote:
| The argument is, that in case of sudo, the caller
| (potential attacker) controls the environment. In many
| cases, software or libraries are not made with a hostile
| environment in mind. Think of LD_PRELOAD or PATH ...
|
| When there's a daemon running in the background, the attack
| surface is more commonly understood. The environment is not
| under attacker control.
|
| Libraries rarely treat data from socket as "trusted" but
| often blindly trust environment variables, or
| stdin/stdout/stderr.
| arp242 wrote:
| That has nothing to do with setuid, and is a very
| different argument from an unqualified "suid feature is
| huge security hole."
|
| sudo etc. already clear much of the environment. And
| you're going to want to keep some of it because people
| expect "sudo foo" to work (which you can't do without
| PATH).
| gnuser wrote:
| Good stuff. Imagine this though: ssh as user access control using
| a multiuser system such as gnu/linux
|
| byw everyone should be using ed25519 or at least 2048+
| RecycledEle wrote:
| It seems like a way for Fed.Gov to know everything we do on our
| computers.
|
| Kill it with fire.
| RecycledEle wrote:
| They have some rule hidden somewhere that communications
| through sockets is less private than things in the terminal.
| kccqzy wrote:
| I did something similar a decade ago (well without the UNIX
| socket bit, but just a separate sshd listening on localhost only
| and also no need to deal with SCM_RIGHTS). Nothing good or bad
| came out of it. I simply got bored and didn't bother porting this
| setup to the next machine.
| coretx wrote:
| This is not a solution, it's a workaround. One that breaks with (
| outdated ) system design doctrines and therefore is likely to
| spawn more cans of worms and will certainly increase the amount
| of technical debt at present.
| ketily wrote:
| This reminds me a little of plam 9 and inferno in treating local
| resources and network resources with a uniform protocol
| tankenmate wrote:
| One issue I see with this is Single User Mode (aka recovery mode
| in grub (or similar) boot loader). Now you can't login as root to
| recover from init (systemd) configuration issues without having
| alternate boot media to get you access. I know it might sound
| pedantic but I used just this feature two days ago while
| upgrading a machine to a newer Linux release (the upgrade
| introduced an issue with the systemd / netplan config that got
| systemd into a loop due to deprecated keywords in the netplan
| config).
| joveian wrote:
| If you want traditional single user mode that drops you to a
| root shell even though your root account is locked add
| SYSTEMD_SULOGIN_FORCE=1 to the environment of rescue.service
| and emergency.service (systemctl edit rescue.service). Of
| course that exact solution isn't always a good idea depending
| on the situation but in general that situation can be delt with
| differently from normal access while running correctly.
| tankenmate wrote:
| Ouch, that's a major security issue if configured that way.
| That's something I'll want to add to my hardening checks.
| the8472 wrote:
| One of the issues with ssh is that spawning processes isn't part
| of the protocol. And it's a remote protocol, so it can't pass
| local resources to the child. So you can't pass a null-separated
| array of arguments, pass extra file descriptors or specify an
| executable. Instead it just passes a string to a server-
| configured shell. So you need to shell-escape things and know
| which shell is running on the server side.
|
| To use SSH as a proper sudo replacement it'd need something
| closer to posix_spawn as an extension.
| jwilk wrote:
| Bug report about the shell indirection:
|
| https://bugzilla.mindrot.org/show_bug.cgi?id=2283
| didntcheck wrote:
| I've used ssh to localhost as a hack for a backup-to-external-
| drive script (using Borg iirc) where I wanted the source reading
| and backup writing to be done as different users. There may have
| been a more elegant solution but it worked well enough
| YesThatTom2 wrote:
| Usenix LISA (now called SRECon) had a paper about this technique
| in 2004:
|
| https://www.usenix.org/legacy/publications/library/proceedin...
|
| Those who ignore Usenix are doomed to repeat it ... 20 years
| later.
| wooptoo wrote:
| Isn't this what systemd run0 is now doing?
| There's a new tool in systemd, called "run0". Or actually, it's
| not a new tool, it's actually the long existing tool "systemd-
| run", but when invoked under the "run0" name (via a symlink) it
| behaves a lot like a sudo clone. But with one key difference:
| it's *not* in fact SUID. Instead it just asks the service manager
| to invoke a command or shell under the target user's UID. It
| allocates a new PTY for that, and then shovels data back and
| forth from the originating TTY and this PTY. Or in other words:
| the target command is invoked in an isolated exec context,
| freshly forked off PID 1, without inheriting any context from the
| client (well, admittedly, we *do* propagate $TERM, but that's an
| explicit exception, i.e. allowlist rather than denylist).
| One could say, "run0" is closer to behaviour of "ssh" than to
| "sudo", in many ways.
|
| - https://mastodon.social/@pid_eins/112353324518585654
| dheera wrote:
| > I changed the root password
|
| If you're going to set a root password, you might as well just do
| this and if I'm not mistaken it accomplishes everything you want
| alias sudo="su -c"
___________________________________________________________________
(page generated 2024-06-23 23:02 UTC)