[HN Gopher] The 'Invisibility Cloak' - Slash-Proc Magic
___________________________________________________________________
The 'Invisibility Cloak' - Slash-Proc Magic
Author : lapnect
Score : 60 points
Date : 2024-11-08 06:54 UTC (16 hours ago)
(HTM) web link (dfir.ch)
(TXT) w3m dump (dfir.ch)
| iwwr wrote:
| Could you use a unionfs like overlay2 for more advanced pid
| hiding?
| tetha wrote:
| Interesting. What are the legitimate use cases to not treat /proc
| as readonly, and what are legitimate use cases to mount around
| and especially bind-mount random filesystems around in /proc?
|
| Like, my first impulse is "Why do we allow this?" And I guess,
| sure, the answer is "root is allowed to do this, because root is
| never not allowed". And sure I very much dislike my computer
| telling me "Nay I cannot do that", hence why I have no windows
| anymore at home.
|
| But there is some stuff that seemingly doesn't have any
| legitimate use case on a server. And even if protections from
| that stuff keep me from fixing some situations, I can still nuke
| and rebuild it in an hour or so.
| netsec_burn wrote:
| I can answer the writing to /proc one. It is sometimes useful
| to hotpatch running programs with /proc/pid/mem.
| tetha wrote:
| And that's what I'm getting at, and where I'd like the
| community to improve in discussions. In what context do you
| need it, and how much, and what would your alternatives be?
|
| Because, the amount of different contexts linux is being used
| in, and the different threat levels are vastly different.
|
| For example, I'm aware that the industrial and embedded world
| does wild things at times. Because it's hard to establish
| redundancy and replacability there. Because the system is
| attached to a $750k lathe. However, that thing is not
| networked, and physical access is controlled by people with
| guns. Do whatever you need to keep this thing running, as
| horrid as it may be.
|
| On the other hand, I have a fleet of loadbalancers and their
| job is to accept traffic from all criminals in this world,
| and then some legitimate users as well. I can reset them to
| base linux and have them back operational in 10 minutes or
| so. Things modifying loaded code in memory outside of some
| very specific situations like service startup on these
| systems is terrifying and entirely not necessary.
|
| So I would be very happy with a switch to turn that off, even
| though some other use cases wouldn't need it or wouldn't be
| able to use it at all.
| aftbit wrote:
| SELinux could prevent this, if that is what you wanted.
| teddyh wrote:
| From systemd.exec(5):
|
| --
|
| ProcSubset=
|
| Takes one of "all" (the default) and "pid". If "pid", all files
| and directories not directly associated with process management
| and introspection are made invisible in the /proc/ file system
| configured for the unit's processes. This controls the
| "subset=" mount option of the "procfs" instance for the unit.
| For further details see _The /proc Filesystem_2. Note that
| Linux exposes various kernel APIs via /proc/, which are made
| unavailable with this setting. Since these APIs are used
| frequently this option is useful only in a few, specific cases,
| and is not suitable for most non-trivial programs.
|
| 2. The /proc Filesystem:
| <https://docs.kernel.org/filesystems/proc.html#mount-options>
| akira2501 wrote:
| > What are the legitimate use cases to not treat /proc as
| readonly,
|
| Only some parts of proc are "read only." /proc/sys is filled
| with writable controls.
|
| > my first impulse is "Why do we allow this?"
|
| The user is allowed to do whatever they like with their
| machine. It's the reason I use linux. It never puts me in a
| position where "system policies" or other default "security
| theater" nonsense disadvantages me on my own hardware.
|
| If you're that concerned you can easily add a policy framework,
| like SELinux, or others, which would prevent this from
| happening or raise an exception if it does.
|
| > that seemingly doesn't have any legitimate use case on a
| server.
|
| There are dozens of other ways to achieve this same effect that
| rely on mechanisms that have legitimate use cases. In
| particular if you are root you will not struggle to find ways
| to hide processes. In this case you can just observe
| "/proc/mounts" to see that something perfidious is occurring.
|
| > I can still nuke and rebuild it in an hour or so.
|
| As long as there is no important data at rest within the
| server. This isn't always the case.
| snarfy wrote:
| One of the solutions listed to discovering this is to investigate
| /proc/mounts and look for these type of mounts. Couldn't you use
| the same trick on /proc/mounts itself?
| chatmasta wrote:
| I had the same thought, but I suspect that would break the
| mount. It might make the entire /proc/mounts directory appear
| empty but none of the mounts would work.
| akira2501 wrote:
| > Couldn't you use the same trick on /proc/mounts itself?
|
| Unfortunately, yes. 'bind' allows mount to bind over individual
| files and not just directories. Which is a little bit insane.
|
| In any case, if you are suspicious, 'umount /proc/mounts'. It
| either returns ok or it returns "umount: /proc/mounts: not
| mounted."
| LegionMammal978 wrote:
| One way to detect when this has occurred is to use fstatfs() [0]:
| it will tell you whether an fd truly belongs to a procfs, or
| whether it belongs to some other kind of filesystem. Of course,
| you still have the issue of one part of a procfs being bind-
| mounted onto another part of a procfs (or onto a different
| procfs). For that, one mitigation is to double-check the st_dev
| of every file down the chain. But it still doesn't guarantee that
| you haven't been led into a recursive bind-mount: for that you
| have to use tricks like checking rename() error codes, or some of
| the fancy new openat2() flags, to test the absence of a mount-
| point boundary.
|
| Personally, my stance is to just blindly trust whatever /proc
| tells you, except in really unusual security models. Users can
| only end up hurting themselves by putting nonsensical things in
| there. (The same way no one should bother checking that /dev/null
| isn't a regular file, even though root can easily make it one.)
|
| [0] https://man7.org/linux/man-pages/man2/statfs.2.html
___________________________________________________________________
(page generated 2024-11-08 23:01 UTC)