Hacker News Reader

Comment by jordemort | Hacker News Reader

If you have the privilege to pull off bind-mounting on top of a particular process directory in /proc you should also be able to mount something on top of /proc itself that will present a false /proc/mounts and conceal your trickery. I experimented a bit and wasn't able to bind a single file on top of /proc/mounts and I seem to be having trouble getting procfs to participate in an overlayfs, but if you were really dedicated you could construct a whole fake /proc by hand, or create something using FUSE to create a /proc that redacts anything you want, including mountpoints.

View on HN

If you have root you can just reboot or kexec and embed yourself at kernel level.

The trick is to hide in plain sight. Call your process “tracker-miner-fs” (common suspiciously named GNOME process”). When the system administrator sees your process eating up huge amount of CPU time and does a web search, they’ll come to the conclusion it’s just GNOME being GNOME.

You... I don't know if I love you or hate you.

Signed, greybeard gnu/linux admin who hates procs like that!

edit: this is also why lsof, ss, strace, and bpftrace etc., are helpful

creating a whole fake proc is simple. I mean the code is already in the kernel as a module. Just copy it, put a few if/else's in the code to control what its readdir ( this case just pid's there's proc_readdir() that calls proc_pid_readdir(), just modify that very simply).

mount is a bit harder (as its calls into code that is more in the core kernel fs code, but one can just reimplement it oneself, to filter out the mounts you don't want to show.

If you have root of course, you can do anything, BUT -- could a eBPF module be loaded into the kernel to just filter the syscalls to hide some nefarious process? This simplifies the 'evil VM' attack. Does eBPF have anything that could plausably help with that?

https://sysdig.com/blog/ebpf-offensive-capabilities/

Pretty sure you can do this with standard MAC ala SELinux/AppArmor.

A variant of hiding in plain sight for a backdoor if you have a webserver: create a directory ". " (dot space) somewhere in the web-application and put your backdoor in that directory.

A sysadmin just would see . . .. as directory entries.

Can you do similar trickery to ensure `mount` doesn't list your bind mount?

I don't see why not - that's just reading from /proc/mounts.

Nitpicking: mount reads from /proc/self/mounts, that is, the mounts as seen from that process. This is how tricks such as chroot jails work, as they present a different mount set and filesystem tree from the base system.

Same thing, really - /proc/mounts is a symlink to /proc/self/mounts.

Fair enough, though casual readers may not realise this.

chroot is a different, older system that pre-dates different mount namespaces.

My understanding is that chroot presently does make use of the different mount namespaces, though I could be wrong here.

How did chroot used to work in this regard? Were mountpoints outside the chroot jail itself accessible? Because if so, that ... would violate some key points of using a chroot jail in the first place. Though if chroot applied strictly to the filesystem and not mount points that might still offer benefits, and I seem to recall running into ... unexpected behaviours ... using chroots in the past.

The classic chroot(2) system call just changes the directory entry that's used for the root in that process. It only affects pathname resolution (including resolution of the pathnames in symbolic links).

If an unconstrained uid zero process is inside the chroot but can access or create device nodes, it can mount devices within the chroot just fine.

When you create a new mount namespace, the kernel creates a copy of every mount reachable from the filesystem (as visible to the process creating it). Then, it changes the current process's root directory and current directory to point to the same paths in the corresponding mounts. Changing a process's root via chroot is otherwise a totally separate operation.

Interesting. Could you not perhaps tank the system attempting something like that?

How? I don't think the kernel cares what the directory looks like - userspace will break in funny ways, but you can boot without procfs even mounted (well, I say boot, but more like "you can start a shell and some things will still work")

TIL that the kernel presents /proc as a convenience to the user, and does not actively read from it

It might help to think of how it's implemented:

When your application calls open() or read() or stat() or whatever, it passes through libc and then makes a syscall to ask the kernel "hey, give me a file handle for /proc/foo", "hey, give me the first 500 bytes from this file handle", etc. Then in the kernel, that syscall triggers a function that figures out what filesystem you're talking to and passes the request to that filesystem driver. AFAIK, the procfs driver just reads (and writes) a bunch of data structures in kernel memory and passes the result through as a filesystem. So the actual underlying data structure does always exist and is a hard requirement for the system to work, but procfs is just a userspace view into that underlying data in the kernel. Incidentally sysfs would be the same - the stuff you see in /sys exists in the kernel regardless, but the kernel doesn't really care whether those data structures are exposed to userspace as a virtual filesystem.

Thanks for this extra context! I wonder now how much latency the system experiences with the procfs driver loaded. I'm guessing virtually none, but still, for a driver that is essentially just decoration for userspace to look at, it seems like there would be some noticeable overhead in having the procfs driver loaded

I wouldn't think so, no. If userspace isn't using it, then there's no latency overhead; the kernel access its own internal data structures the same regardless. If userspace is using it, the kernel still uses its own data structures just the same, but now there's a way for programs to read those data structures. Using the procfs driver doesn't change anything inside the kernel (well, anything important; obviously it exercises the procfs driver code (which also will have its own variables) and there's some data structures that describe mounted filesystems), it just provides an interface to what's already there.

Oh yes, very easily, although you'd be surprised at how much works without a functional /proc.

Reply on news.ycombinator.com