chmod: changing permissions of 'drop_caches': Operation not permitted

tcp6

@eol said:
Of course it fails.
It executes with your current user permissions.

I've tried -rwsr-xr-x and -rwsr-sr-x.
Sorry but I really don't want to fiddle around with the /etc/fstab unless it's a last resort.

FAT32

Create the C code and compile it

dropcaches.c

#include <stdlib.h>
#include <unistd.h>

int main() {
    setuid(0);
    system("/bin/echo 3 > /proc/sys/vm/drop_caches");
    return 0;
}

gcc dropcaches.c -o dropcaches
chmod 4755 dropcaches

EDIT: Modified the system call to use full path

eol

@tcp6 said:

@eol said:
Of course it fails.
It executes with your current user permissions.

I've tried -rwsr-xr-x and -rwsr-sr-x.
Sorry but I really don't want to fiddle around with the /etc/fstab unless it's a last resort.

Sure.
While it might work it has severe security implications.

tcp6

@Janevski said:
So apparently there is a way of doing this, but it is a bad idea from security standpoint:

https://stackoverflow.com/questions/13646925/allowing-a-non-root-user-to-drop-cache

https://km.mk/allowing-a-non-root-user-to-drop-cache.pdf

I've tested it on ubuntu, it seems to work. Sorry i cannot paste the text, CloudFlare thinks i am hacking LET, so i'll post a screen shot.

Exactly what I needed. Kudos for that.

tcp6

@FAT32 said:
Create the C code and compile it

dropcaches.c

#include <stdlib.h>
#include <unistd.h>

int main() {
    setuid(0);
    system("/bin/echo 3 > /proc/sys/vm/drop_caches");
    return 0;
}

gcc dropcaches.c -o dropcaches
chmod 4755 dropcaches

Flawless.

eol

@FAT32 said:
Create the C code and compile it

dropcaches.c

#include <stdlib.h>
#include <unistd.h>

int main() {
    setuid(0);
    system("/bin/echo 3 > /proc/sys/vm/drop_caches");
    return 0;
}

gcc dropcaches.c -o dropcaches
chmod 4755 dropcaches

Not bad.

EDIT:
Code update.

FAT32

@FAT32 said:
Create the C code and compile it

dropcaches.c

#include <stdlib.h>
#include <unistd.h>

int main() {
    setuid(0);
    system("/bin/echo 3 > /proc/sys/vm/drop_caches");
    return 0;
}

gcc dropcaches.c -o dropcaches
chmod 4755 dropcaches

It works.

tcp6

Sure works on a KVM VPS, however on an OpenVZ VPS, that's a no-go.

FAT32

After reading the comment and the StackOverflow post by @Janevski, I forgot that the "PATH" environment variable can be changed to a malicious one.

Please change the system call to the following to secure the system:
system("/bin/echo 3 > /proc/sys/vm/drop_caches");

tcp6

@FAT32 said:
After reading the comment and the StackOverflow post by @Janevski, I forgot that the "PATH" environment variable can be changed to a malicious one.

Please change the system call to the following to secure the system:
system("/bin/echo 3 > /proc/sys/vm/drop_caches");

Makes sense, would you mind editing your initial code snippet as well? In case someone else stumbles on it someday and doesn't bother reading further.

FAT32

@tcp6 said:
Makes sense, would you mind editing your initial code snippet as well? In case someone else stumbles on it someday and doesn't bother reading further.

I did, perhaps you and @eol can update the quote as well

tcp6

@FAT32 said:

@tcp6 said:
Makes sense, would you mind editing your initial code snippet as well? In case someone else stumbles on it someday and doesn't bother reading further.

I did, perhaps you and @eol can update the quote as well

Done on my end.

eol

@FAT32 said:

@tcp6 said:
Makes sense, would you mind editing your initial code snippet as well? In case someone else stumbles on it someday and doesn't bother reading further.

I did, perhaps you and @eol can update the quote as well

Done.

tcp6

Will all that being said, OpenVZ really needs to die.

• Can't swapon -a.
• Can't flush memory buffers.
• Can't use FUSE properly if it hasn't been compiled as a module on the host node.

I can't believe people in the hosting industry are still using OVZ.

eol

@tcp6 said:
Will all that being said, OpenVZ really needs to die.

This.

eol

Now there is still a security problem.
One could replace the echo binary with something slightly more malicious.
But anyway problem solved.

dahartigan

@tcp6 said:
Will all that being said, OpenVZ really needs to die.

• Can't swapon -a.
• Can't flush memory buffers.
• Can't use FUSE properly if it hasn't been compiled as a module on the host node.

I can't believe people in the hosting industry are still using OVZ.

We love OVZ if we don't need to do the above mentioned things. For everything else there is KVM or bare back metal.

eol

@dahartigan said:
We love OVZ if we don't need to do the above mentioned things. For everything else there is KVM or bare back metal.

Really?
Come on...

dahartigan

@eol said:

@dahartigan said:
We love OVZ if we don't need to do the above mentioned things. For everything else there is KVM or bare back metal.

Really?
Come on...

Oh, and I'd never put anything sensitive anywhere near an OVZ.

tcp6

gaia 2.6.32-042stab128.2

root@gaia:~# id
uid=0(root) gid=0(root) groups=0(root)

root@gaia:~# fallocate -l 1G /mnt/1GB.swap

root@gaia:~# mkswap /mnt/1GB.swap
Setting up swapspace version 1, size = 1048572 KiB
no label, UUID=19b804ff-bbf9-4b20-ac28-00d455696f51

root@gaia:~# chmod 0600 /mnt/1GB.swap

root@gaia:~# swapon /mnt/1GB.swap
swapon: /mnt/1GB.swap: swapon failed: Operation not permitted

root@gaia:~# echo 3 > /proc/sys/vm/drop_caches
-su: /proc/sys/vm/drop_caches: Permission denied

Piece of shit.

dahartigan

Get a dedicated server and call it a day old chap.

eol

@dahartigan said:
Get a dedicated server and call it a day old chap.

Agreed.

EDIT:
Nothing better than idling a bunch of dedicated servers.

tcp6

@eol said:
Now there is still a security problem.
One could replace the echo binary with something slightly more malicious.
But anyway problem solved.

One work-around I am thinking of regarding the "echo binary issue" would be to use busybox, at least that's how it is done on embedded systems with minimal kernels and space constraints.

dahartigan

@eol said:

@dahartigan said:
Get a dedicated server and call it a day old chap.

Agreed.

EDIT:
Nothing better than idling a bunch of dedicated servers.

It's not idling if they are running tmux + htop.

eol

@tcp6 said:

@eol said:

One work-around I am thinking of regarding the "echo binary issue" would be to use busybox, at least that's how it is done on embedded systems with minimal kernels and space constraints.

While that might work... don't you think busybox is somewhat limited?

EDIT:
Quote.

tcp6

@dahartigan said:
It's not idling if they are running tmux + htop.

You forgot screen! You n00b.

dahartigan

@tcp6 said:

@dahartigan said:
It's not idling if they are running tmux + htop.

You forgot screen! You n00b.

Tmux is screen's sexy sister.

tcp6

@eol said:
While that might work... don't you think busybox is somewhat limited?

That depends on "how" you've compiled it actually.

See: https://busybox.net/downloads/BusyBox.html

Edit: Busybox can even have it's own internal httpd, ftpd, nc and so forth. Back in my days some rootkits were actually nothing but modified busybox binaries disguised as legit daemons running on compromised hosts.

eol

@dahartigan said:
It's not idling if they are running tmux + htop.

True.

tcp6

@dahartigan said:

@tcp6 said:

@dahartigan said:
It's not idling if they are running tmux + htop.

You forgot screen! You n00b.

Tmux is screen's sexy sister.

Yeah but when you're drunk to the boot, you'd still fuck the uglier sister regardless.