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

dahartigan

@tcp6 said:

@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.

Any port will do in a storm.

tcp6

@dahartigan said:
Any port will do in a storm.

Packet storm anyone?

More seriously; this thread has ran it's course, let it die plzkthx.

eol

@dahartigan said:

@tcp6 said:

@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.

Any port will do in a storm.

Of course you are talking about penetration tests and SQL injection.

dahartigan

@tcp6 said:

@dahartigan said:
Any port will do in a storm.

Packet storm anyone?

More seriously; this thread has ran it's course, let it die plzkthx.

Lawl.

@eol said:

@dahartigan said:

@tcp6 said:

@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.

Any port will do in a storm.

Of course you are talking about penetration tests and SQL injection.

That's turning me on.

muffin

Have you tried turning it off and on?

Janevski

@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.

No.

Less overhead.

OpenVZ containerization dying is bad, very bad.

OpenVZ dead + high ipv4 price = a whole hierarchy class of budget low end boxes will be no more

The end is... something.

eol

@tcp6 said:

@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.

Been looking at that link.
The list of commands is even more extensive than I thought.

dahartigan

@Janevski said:

@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.

No.

Less overhead.

OpenVZ containerization dying is bad, very bad.

OpenVZ dead + high ipv4 price = a whole hierarchy class of budget low end boxes will be no more

The end is... something.

Start hoarding them now then you can profit. The end is at some point in the future.

eol

@dahartigan said:

@Janevski said:

@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.

No.

Less overhead.

OpenVZ containerization dying is bad, very bad.

OpenVZ dead + high ipv4 price = a whole hierarchy class of budget low end boxes will be no more

The end is... something.

Start hoarding them now then you can profit. The end is at some point in the future.

Yeah.
OVZ will get scarce and prices will skyrocket in the near future.

tcp6

@eol said:

@tcp6 said:

@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

Been looking at that link.
The list of commands is even more extensive than I thought.

Technically they're called "applets" rather than "commands", but can we let this thread die plz?

eol

Ok.
I will try.

Janevski

@dahartigan said:

@Janevski said:

@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.

No.

Less overhead.

OpenVZ containerization dying is bad, very bad.

OpenVZ dead + high ipv4 price = a whole hierarchy class of budget low end boxes will be no more

The end is... something.

Start hoarding them now then you can profit. The end is at some point in the future.

It doesn't work that way.

Hosts just say:

"dear mister cheapass,

Look buddy, we know you love our low profit margin openvz, but it's time, Old Yeller had to go.

We'll migrate you to our somewhat expensive plan. Backup your data.

Thank you for understanding.

PS: Btw, how is life there in Dumbfuckistan? Do You people even know what hot water is?

Worst Regards,

Your lovely host"

eol

@tcp6 said:
... but can we let this thread die plz?

Daniel15

@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.

You forgot one major point: It uses a 10-year-old kernel version (2.6.32), and the new OpenVZ version that people might migrate to is using a newer version (3.10) that's already EOL'd, so it's going to be obsolete as soon as it rolls out.

@eol said:
try to change the /proc filesystem permissions in /etc/fstab

Please don't do this! There's lots of stuff in /proc that regular users should not be able to touch (like the environment of other user's processes, as passwords and access tokens are often passed as environment variables), so you shouldn't mess with the permissions of the entire thing.

gfa

@tcp6 said:
Ummm couldn't get it to work either.

-rwsr-sr-x 1 root root 44 Dec 30 09:46 /bin/ram.sh

stat /bin/ram.sh
File: /bin/ram.sh
Size: 44 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 261194 Links: 1
Access: (6755/-rwsr-sr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2018-12-30 09:50:55.848827387 +0800
Modify: 2018-12-30 09:46:46.799199077 +0800
Change: 2018-12-30 09:50:52.676755709 +0800

cat /bin/ram.sh

!/bin/sh

echo 3 > /proc/sys/vm/drop_caches

ram.sh
/bin/ram.sh: 2: /bin/ram.sh: cannot create /proc/sys/vm/drop_caches: Permission denied

suid/sgid does not work on scripts (anything starting with !# actually)

More info https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts

eol

@Daniel15 said:

@eol said:
try to change the /proc filesystem permissions in /etc/fstab

Please don't do this! There's lots of stuff in /proc that regular users should not be able to touch (like the environment of other user's processes, as passwords and access tokens are often passed as environment variables), so you shouldn't mess with the permissions of the entire thing.

Correct and I mentioned it is questionable from a security standpoint.
Although it will do what the OP requested.
With a price though.

FlamesRunner

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

In general, files in /bin should not be replaceable by normal users anyway. If the malicious actor is able to change the file, they effectively have root, so the code posted should be fine, if your permissions are set correctly.

dahartigan