PaXCTL - A bit like EMET?

[Hungry Man]

I was looking around and I found paxctl and installed it, running it give sme:

usage: paxctl <options> <files>

options:
	-p: disable PAGEEXEC		-P: enable PAGEEXEC
	-e: disable EMUTRMAP		-E: enable EMUTRMAP
	-m: disable MPROTECT		-M: enable MPROTECT
	-r: disable RANDMMAP		-R: enable RANDMMAP
	-x: disable RANDEXEC		-X: enable RANDEXEC
	-s: disable SEGMEXEC		-S: enable SEGMEXEC

	-v: view flags			-z: restore default flags
	-q: suppress error messages	-Q: report flags in short format
	-c: convert PT_GNU_STACK into PT_PAX_FLAGS (see manpage!)
	-C: create PT_PAX_FLAGS (see manpage!)

Anyone try this?

[Hungry Man]

So I've used this with my PAX kernel. No idea if it's working but it says it's working and it sure as hell can break things. Got all flags with xchat and VLC no issue. Not messing with Chrome - no reason to break what works. Gonna set some other things up later.

[dw426]

Enjoy your new toy, lol. I would hardly find EMET-like abilities necessary under Linux, but my interest is peaked and I'll watch the thread.

[Hungry Man]

Seems alright so far. I don't think it's really necessary but if it doesn't break compatibility I may as well use it.

[dw426]

Originally Posted by Hungry Man

Seems alright so far. I don't think it's really necessary but if it doesn't break compatibility I may as well use it.

I hear you on that Lol, a friend of mine pops in here from time to time and came across this thread and the "What's your Linux security?" thread. First thing he said was "What the hell, man? If I have to put all that on there, I might as well stick with "Windoze!". I had to remind him that this is Wilders I'm actually glad we have things like this, Apparmor and such. It may not be necessary, but it's nice to have the options available.

[Hungry Man]

lol I wouldn't tell anyone that they need to compile their own kernels and patch with pax/grsec and configure apparmor etc to be secure but I definitely do enjoy having the ability to.

[funkydude]

Originally Posted by dw426

It may not be necessary, but it's nice to have the options available.

It is necessary. Or rather, it would be necessary if Linux shot into popularity tomorrow. It's all well and good free-riding on it's low market share right now, but people like to be protected for what tomorrow may bring. It's not like these tools are heavy or anything.

[Hungry Man]

Well, sorta. I would agree that something like EMET/PaxCTL is necessary on Linux if it weren't for the already strong sandboxing, which I've set up on literally every program that I've installed and quite a few system programs as well.

Still, layers are nice. And I can apply PaxCTL on programs that I might not as easily sandbox.

Most people don't go to the trouble of sandboxing everything though. And most Linux distros are not immensely secure by default. And something like paxctl is probably easier for Joe User to figure out than AppArmor, let alone SELinux.

OTOH, none of this is really "security by default." And the scary thing is, I'm not sure how you could implement truly secure defaults without breaking functionality for some people. Antivirus companies tried that on Windows, and we all know where that ended up.

[Hungry Man]

A few services run with apparmor by default on Ubuntu and there are a dozen profiles for users.

I agree that it's not by default, but the tools are there and pretty damn easy to use.

But a large part of Linux security is patch management. All of my programs are always up to date, I don't have to touch any of them. Imagine if all Windows installations never had out of date Flash/Java plugins or an out of date browser.

I suppose. A lot of people consider the lack of package management to be one of Windows' strong points. Installers come with all their dependencies packaged, you don't have to do anything.

That said, third-party updaters are awful and Windows' own updater is even more awful. Linux package management may be a necessary evil.

[Hungry Man]

Installers come with all their dependencies packaged, you don't have to do anything.

This is how it is in Linux as well. If a package has a dependency it'll list it and it'll be installed. Apt-get checks for them.

[dw426]

Originally Posted by funkydude

It is necessary. Or rather, it would be necessary if Linux shot into popularity tomorrow. It's all well and good free-riding on it's low market share right now, but people like to be protected for what tomorrow may bring. It's not like these tools are heavy or anything.

Even if Linux popularity shot up into the stratosphere tomorrow, even without such tools, Linux would have quite an advantage over stock Windows as far as security goes. I'm not in the "Linux is untouchable" camp, not even a little. But there are still security advantages to Linux besides "few use it". It most certainly helps, but it isn't the only thing keeping Linux from becoming malware heaven.

[Hungry Man]

And I will wholeheartedly second that.

I think the biggest threat, in terms of Linux's security future on the desktop, is social engineering. Most desktop distros use graphical updaters... All you need is a nice fake updater GUI that can be executed through a browser exploit. User sees update prompt, enters the root password -> bam, owned, onward to keylogger-and-stolen-PIN-ville. This (usually) won't work on power users, but if Linux hits it big on the desktop, most users will not be power users.

Hey, it works on Windows...

(Of course, I'm assuming here that root access is needed to capture keystrokes. I'm not sure how true that is though... I mean, xkbindkeys captures keystrokes and it works fine under a limited account.)

[Hungry Man]

I don't see social engineering as a huge issue on Linux. Software repos make it way more difficult.

I mean, you can still have an email being like "hey, here are some family photos! click and run!"

And then it links to a .deb or something.

[dw426]

Originally Posted by Gullible Jones

I think the biggest threat, in terms of Linux's security future on the desktop, is social engineering. Most desktop distros use graphical updaters... All you need is a nice fake updater GUI that can be executed through a browser exploit. User sees update prompt, enters the root password -> bam, owned, onward to keylogger-and-stolen-PIN-ville. This (usually) won't work on power users, but if Linux hits it big on the desktop, most users will not be power users.

Hey, it works on Windows...

(Of course, I'm assuming here that root access is needed to capture keystrokes. I'm not sure how true that is though... I mean, xkbindkeys captures keystrokes and it works fine under a limited account.)

You're forgetting two things when it comes to fake updaters:

1. Almost all of them are labeled as security updates.

2. All updates from programs installed in Linux via the repos or that come already installed, are pushed through the repos instead of outside sources. It's not like in Windows, where the program may use an outside source and give you a link to click and download from a website.

Also, generally if you were to click on such an alert that suddenly popped up on a website the exploit might download, but it won't be able to finish the job in Linux.

We can go one better than that though: how about launching a process that forks and waits in the background, querying the actual update server for updates? And then gives the fake notice (with text about real updates) when the updates become available. Just for kicks, once it had the root password it could invoke the actual updater to install updates for real, while whatever it launched as root sat in the background and recorded the user's keystrokes.

All the user would see is the updater window popping up twice. If they weren't very experienced they wouldn't think twice about it. Heck, even an experienced user who did think twice about it might not suspect malware.

Also, generally if you were to click on such an alert that suddenly popped up on a website the exploit might download, but it won't be able to finish the job in Linux.

Because files on UNIX are by default created without execute privileges? There are ways around that though. An arbitrary code execution bug in e.g. Firefox's Javascript engine might work in Linux as well as Windows.

I do think Linux has generally better default-deny policies than Windows, but I think that, if it becomes more heavily used, it will be targeted more (and more successfully). If malware writes find that their tactics for Windows aren't working for Linux, they will change their tactics, because that's how they roll.

[Hungry Man]

We can go one better than that though: how about launching a process that forks and waits in the background, querying the actual update server for updates? And then gives the fake notice (with text about real updates) when the updates become available. Just for kicks, once it had the root password it could invoke the actual updater to install updates for real, while whatever it launched as root sat in the background and recorded the user's keystrokes.

Yes... but this is implying that the system is already infected. And not only would it need to be infected it would also need to have root.

So at this point you're already screwed, why would it need to provide you with fake updates if it already has root?

An arbitrary code execution bug in e.g. Firefox's Javascript engine might work in Linux as well as Windows.

It would. But your Firefox would be sandboxed with Apparmor hopefully and therefor:
1) The exploit is trapped and even potentially mitigated because of this
2) The exploit can not execute anything other than what the apparmor profile dictates through MAC policy
3) The exploit would be forced in RAM and completely unable to mmap anything, which kinda leaves it dead in the water. It can probably hack your Firefox session but it can't write to most things in the profile anyways.

I do think Linux has generally better default-deny policies than Windows, but I think that, if it becomes more heavily used, it will be targeted more (and more successfully). If malware writes find that their tactics for Windows aren't working for Linux, they will change their tactics, because that's how they roll.

Linux is already targeted though. It's not like the kernel is some untested "maybe it's secure" type thing - it's been getting hacked for years lol we know how servers are attacked.