At the 2015 Kernel Summit, Kees Cook said, he talked mostly about the things that the community could be doing to improve the security of the kernel. In 2016, instead, he was there to talk about what had actually been done. Kernel hardening, he reminded the group, is not about access control or fixing bugs. Instead, it is about the kernel protecting itself, eliminating classes of exploits, and reducing its attack surface. There is still a lot to be done in this area, but the picture is better than it was one year ago.
One area of progress is in the integration of GCC plugins into the build system. The plugins in the kernel now are mostly examples, but there will be more interesting ones coming in the future. Plugins are currently supported for the x86, arm, and arm64 architectures; he would like to see that list grow, but he needs help from the architecture maintainers to validate the changes. Plugins are also not yet used for routine kernel compile testing, since it is hard to get the relevant sites to install the needed dependencies.
Linus asked how much plugins would slow the kernel build process; linux-next maintainer Stephen Rothwell also expressed interest in that question, noting that "some of us do compiles all day." Kees responded that there hadn't been a lot of benchmarking done, but that the cost was "not negligible." It is, though, an important part of protecting the kernel.
(Score: -1, Offtopic) by Anonymous Coward on Saturday November 12 2016, @06:32AM
Just thinking about penguins pecking my nuts makes my pecker rigid.
(Score: 2) by jasassin on Saturday November 12 2016, @06:48AM
If you have user access to the system, you can acquire root.
Does anyone know of any way to do remote logging of login times, keystrokes, applications ran and what files they accessed like a total package of telemetry for each person logged into the Linux system?
I've always wondered about this. Total logging over everything done by every user to a remote machine that cannot have the logs altered. You get the gist of it.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 1, Funny) by Anonymous Coward on Saturday November 12 2016, @06:50AM
Sure thing, just install Windows 10.
(Score: 2) by jasassin on Saturday November 12 2016, @06:59AM
I knew this was coming when I posted that... (sighs)
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: -1, Troll) by Anonymous Coward on Saturday November 12 2016, @07:08AM
That's what you get for advocating Linux spyware.
(Score: 2) by jasassin on Saturday November 12 2016, @07:32AM
It's not spyware if you are logging your own machines, and the people logged into them are informed of the the logging.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0, Disagree) by Anonymous Coward on Saturday November 12 2016, @08:24AM
Yeah dude, that's the same bullshit rationalization I told myself back in high school when I installed InvisibleOasis on the teacher's Mac Classic and key logged all his passwords. My high school didn't even have internet when I went there. That's how long I've been doing this shit, bitch. I'm old enough to know better. All key loggers are spyware. There are no exceptions.
(Score: 0) by Anonymous Coward on Saturday November 12 2016, @08:37AM
Well fuck me, I didn't believe it, but "Space Rogue's Whacked Mac Archives" is still online. I expected that sexless loser would have been long dead by now.
(Score: 1, Offtopic) by jasassin on Saturday November 12 2016, @08:51AM
Keywords there being teacher's Mac.
Get back to me when you use man pages (with no prior C knowledge) to code (in about 30 minutes) a fake login for vt100 dumb terminals on an AIX system (and it works flawlessly).
Yay! You installed a program on a Mac, I wrote a program in C to fake a login screen and steal the login/password... and I'm the bitch?
We have a word for people like you: chomper
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0) by Anonymous Coward on Saturday November 12 2016, @09:13AM
You had man pages? When I was single digits years old I was coding login prompts in Applesoft Basic with nothing but a book from the public library for the urban poor.
(Score: 2) by jasassin on Saturday November 12 2016, @09:24AM
I give up.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 2) by Gaaark on Saturday November 12 2016, @06:04PM
Yeah, but the AC gives up, going uphill both ways in a snow storm while dragging his dead daddy by the penis!
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 1, Offtopic) by art guerrilla on Saturday November 12 2016, @12:38PM
um, i believe the correct terminology now is 'person pages'...
get with the times, knuckle-draggers...
(Score: 2) by maxwell demon on Saturday November 12 2016, @08:45AM
If the users have no choice but to accept it, then it's still spying. The only way it is not spying is if the users themselves decide to allow you to collect that information, and can at any time revert that decision without negative consequences to themselves.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by jasassin on Saturday November 12 2016, @09:06AM
Max what we have here is a failure to communicate. I'm talking about running my own Linux machine, letting users log into it via ssh (telnet who gives a shit) with a prompt that says everything is logged. A user by definition is somone who is using, and if they don't want anymore data collected they stop using.
I am not seeing any problems with this.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 0) by Anonymous Coward on Saturday November 12 2016, @09:21AM
Richard Matthew Stallman disapproves of your methods. Repent now, sinner!
(Score: 0) by Anonymous Coward on Saturday November 12 2016, @09:51AM
I am not aware of any packages that perform full user audit-trail logging. This [ekransystem.com] looks like it should give you names of players in this market (I've never used any of these products).
(Score: 2) by butthurt on Saturday November 12 2016, @08:44AM
The default logging utility in Fedora, Debian and openSUSE has remote logging capability--try man rsyslogd.
https://en.wikipedia.org/wiki/Rsyslog [wikipedia.org]
(Score: 2) by jasassin on Saturday November 12 2016, @09:14AM
syslog seems extremely limited... im not even sure it can send executed shell commands, let alone keystrokes. i'd like every key logged. even wish shell execution it would be trivial to write a program to get around the shell logging. need keystroke logging to be sure.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: -1, Troll) by Anonymous Coward on Saturday November 12 2016, @09:25AM
Fuck you, man. You'll have zero users, and you'll deserve to have zero users.
(Score: 5, Informative) by jasassin on Saturday November 12 2016, @09:36AM
No, fuck you man. I'll have users that use the system for what they are allowed to use it for, and zero users using my system for shady shit.
FYI I answered my own question, yes you can log all the keystrokes in Linux via pam_tty_audit module.
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 4, Interesting) by Snospar on Saturday November 12 2016, @03:30PM
Thanks for persevering with this thread, despite all the negative replies. We have boxes at work that log all our keystrokes and commands, as they are servers used to manage/maintain a large secure network, and I've often wondered how that logging was done. And yes, as a user of those machines I have to agree to this level of monitoring so that we can provide a full audit trail - this is a requirement to achieve the security accreditation that we need to provide secure customer services on the network. In no way do I consider this "Linux Spyware", it's a tool for the White Hats as much as anyone else (and invaluable in finding out who or what caused X to happen even if it was something in error rather than malice).
Huge thanks to all the Soylent volunteers without whom this community (and this post) would not be possible.
(Score: 2) by opinionated_science on Saturday November 12 2016, @01:18PM
just turn on all the logging.
You might need a script to grab the console...
However, it is possible to setup linux to make it *only* possible for a user to see their own resources.
Google an article about "linux without root" from LinuxJournal.
As an aside on a multiprocessor machine (I have 32 cpu from 4 opterons on 2 chips) , it is possible to segregate the system process tree (systemd) from a user activity.
Not perfect, but helps to be paranoid as there are probably as yet, undisclosed back doors in the hardware...
(Score: 0) by Anonymous Coward on Saturday November 12 2016, @04:09PM
Huh? I don't think user access to a machine allows root. That would be lame. Physical access on the other hand generally means all bets are off.
(Score: 2) by Fnord666 on Saturday November 12 2016, @05:51PM
(Score: 0) by Anonymous Coward on Sunday November 13 2016, @03:58AM
"applications run"
(Score: -1, Flamebait) by Anonymous Coward on Saturday November 12 2016, @08:15AM
A good first step.
(Score: -1, Flamebait) by Anonymous Coward on Saturday November 12 2016, @08:27AM
Second step. Linux is shit. You should use macOS.
(Score: -1, Troll) by Anonymous Coward on Saturday November 12 2016, @08:46AM
Let the bloating of Linux continue! I remember when it was actually smaller than Windows. Throw in some more kernel features, pls!
(Score: 4, Insightful) by ticho on Saturday November 12 2016, @09:36AM
Wow, this is one discussion thread where Soylent has completely failed to be useful, and did a full Slashdot, with nothing but primitive flamebait posts. With threads like these, I sometimes feel that five mod points just aren't enough, it's like trying to hold an ocean back with a broom.
(Score: -1, Redundant) by Anonymous Coward on Saturday November 12 2016, @09:42AM
Trolls be so proud.
(Score: 2) by Phoenix666 on Saturday November 12 2016, @11:53AM
Yes, and it's especally sad because there aren't that many articles that fall under the OS category that Soylentils can geek out about. This is the first one for linux in about a year i have seen since the systemd furor died down.
Washington DC delenda est.
(Score: 2) by Gaaark on Saturday November 12 2016, @08:22PM
I think the problem is it's less an OS category than a privacy vs security category.
How much do you value your users privacy vs how well do you want to secure your system. Actually, a pretty contentious issue, depending on who you are: user or manager.
Kind of like citizen vs NSA/FBI etc.
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2, Interesting) by Anonymous Coward on Saturday November 12 2016, @12:48PM
after the kernel is made safe, who manages cgroups?
or on the other side, what about the auxiliary hardware systems (with privileged access to memory or cpu features)?
(Score: 3, Interesting) by Rich on Saturday November 12 2016, @03:06PM
The C language itself could easily be hardened against the vast majority of the classic exploit sources, even while staying source compatible. There are already different accessors for pointers (*) and arrays (or "vectors", as they call'em) ([]). Slap a size count for arrays into the ABI and warn on pointer math unless "#pragma unsafe" is given. Poof. There go all the buffer overflows. Just declare anonymous structure members (gcc got them only recently) welcome citizens of the ecosystem, and you've got everything needed for object inheritance - bonus points for not warning against typecasts to these to get safe downcasts. Or maybe just if they come first in a struct, if you want to keep a bit of type info before actual data, to be safe on that side, too.
You get the idea. The invasiveness of the above is just minimal. And there's a good number of very, very little things that would make C so much more useful and safe. (The overhead for dragging around sizes, btw, would be entirely gulped up by today's superscalarness).
Instead, we get 'restrict', and relatives, because FORTRAN. Even more 'undefined' states. If you're unable to express yourself with a suitably optimal algorithm, stick to your bloody FORTRAN, because that's what it's for. FORmula TRANslator. Let's not start with all the memory types required for atomic operations in the latest standard, because some (probably cancelled) NUMA research project wanted to be covered, too. And for the library, here's a snippet on how to add struct timeval, you inferior grunt, we're generous today. Do as told, or it will miss full moons on a PDP-11.
If the kernel people want to harden their kernel, they might look into having tools for that at the elementary level. So that any reasonably looking stretch of code simply has no undefined states. They're so linked to a GCC (to the point Clang has a hard time), they could easily set those standards.
(Score: 0) by Anonymous Coward on Saturday November 12 2016, @05:05PM
i'm just learning php but i think it would be nice if languages had some security built in. So, if you use it as documented you are more secure by default. You should have to go out of your way to do dangerous stuff. you should get warnings in the log when doing dumb shit.
or are these ideas stupid for some reason?
also, it would be nice if books spent a few chapters on secure development best practices as well as performance or more books should be written on just best practices and application design philosophy as it relates to security and performance. from what i've gleaned so far, it's just a bunch of books on syntax, what things are and /or how to implement features with no concern for security or performance/efficiency. There's even stuff for how to make your code concise and easy to follow or to organize it, with no mention of security or performance ramifications. Is it just php resources that are like this?
(Score: 2) by RamiK on Saturday November 12 2016, @07:29PM
The C language itself could easily be hardened against the vast majority of the classic exploit sources, even while staying source compatible.
No it can't. The closest C came to type safety was Cyclone [thelanguage.org] and that work was abandoned in favor of Rust. Even C's own creators gave up on fixing \ extending C and developed Go [golang.org].
One of LLVM's stepping stones was such an effort: http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf [llvm.org]
The closest thing to an exception I can come up with is in-order execution and\or CPU level parity bytes moving bound-checking to the silicone. But that's only been shown to work in simulators so far.
compiling...
(Score: 2) by Rich on Saturday November 12 2016, @08:13PM
No it can't. The closest C came to type safety was Cyclone
I have to disagree here. All the C-like language development I have seen, including your examples, is indeed some wankage over the developers pet peeves (e.g. "Cyclone for Programmers"). Once one such path (C++, D) gets past the "usable for more than its own demos" stage and gains traction, it mutates into a gravity hole attracting more of the same.
But that doesn't mean it has to be that way. There's a wonderful, simple yet typesafe system programming language in Oberon (https://en.wikipedia.org/wiki/Oberon_(programming_language) [wikipedia.org]) that checks all (but one) of the boxes required for system programming. I don't see why the logic behind that cannot be made to work under a C-like, and initially even C-compatible syntax.
The one remaining box to be checked is that Oberon has a stop-the-world garbage collector for total pointer safety, which is a no-go for many applications. But hey, let's dump that and go back to the simple Pascal model. That's one class of possible bugs, but we can simply live with that. After all we write into DMA registers a few lines away. Or maybe allow a way to sneak in low-overhead ref counting.
Of course, once we're there (remember Oberon compiling the whole system in 15 seconds on a 25 GHz NS32032? Or Turbo Pascal/Delphi in general?) we can as well stay with the Pascal-style syntax to keep all the folks, who think up the lunacy-du-jour in the C world, out. But that wouldn't help with the Linux kernel hardening.
(Score: 2) by Rich on Saturday November 12 2016, @09:03PM
On a 25 GHz NS32032, the whole Oberon System would compile itself in 15 milliseconds. The 32032 wasn't that fast. But it would certainly be a welcome difference to the person who complained "we're compiling all day" in the article ref'd in the submission.
(Score: 2) by RamiK on Saturday November 12 2016, @11:47PM
Oberon's memory model isn't C's and wasn't portable. The late 80's CISCs (National 32000 & Motorola's 68000) were all transitional products. For a brief period of roughly 5-7 years, the die-per-wafer yields during those years allowed CISC to compete against RISC. Now here's the thing, Writing a compiler for these very clean and human readable CISC designs was a joy. You didn't have to stage your compilation. Pipelining was a straightforwards text-book prelude and postlude. The 32000 especially had all generic registers so you didn't have to really worry about anything. It was so good that the Plan 9 (pseudo) assembler kept the 32000 instructions and would wrap native (68000, x86, ARM, MIPS...) instructions to those just because Ken liked working on those machines so much. In did, the Go assembler was Plan 9's assembler up to 1.5. Recently, it was rewritten in Go. But it still uses those very same instructions and wraps around native assembly just because it's so convenient to work with. Pike's ACME still uses Oberon's GUI since, like Ken's love for the 32000, Pike love Oberon's GUI.
Which leads us to the problem: Oberon's design and code, like DSPs, was not too portable when it came to pipelining and managing different registers for different instructions. As a result, Oberon couldn't be made to work as efficiently in later hardware. This is why the latest Oberon implementation is on an FPGA board. So, when you're saying Oberon compiles under 15ms, you're talking about a VERY small and targeted compilation phase and code-base that shouldn't be treated as general purpose as much as it should be compared to DSPs and their respective compilers and (limited) kernels.
Regardless, for what it's worth, the good stuff from Oberon made it to golang in a C-like portable fashion. Additionally, the latest garbage collector research is being poured into Go. More importantly, when I mentioned simulators, I had the Mill architecture [wikipedia.org] in mind which does type-safety on the die through the metadata [millcomputing.com] values. On those machines, while C will run extremely well, I suspect we'll also see garbage collected, type-safe languages getting some REALLY good compilers going.
compiling...