How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
Nearly all of us carry a powerful computer in our pocket that is more than capable of calculating and displaying TOTP [Time-based One-Time Password] tokens. Google recognized this a while back and released a free mobile app called 'Google Authenticator,' available on most mobile platforms. Anyone can set up two-factor authentication for their Google Account using the Authenticator, but the best part is that it's not just limited to Google's services. Since TOTP is an open standard, any infrastructure can use Google Authenticator to provision their own software tokens and implement TOTP-based two-factor authentication for their services."
Posted Feb 14, 2013 21:52 UTC (Thu)
by storner (subscriber, #119)
[Link] (2 responses)
Not so easy to use for authenticating to websites, though.
Posted Feb 14, 2013 22:24 UTC (Thu)
by Henning (subscriber, #37195)
[Link]
Posted Feb 14, 2013 23:19 UTC (Thu)
by mricon (subscriber, #59252)
[Link]
Posted Feb 14, 2013 22:27 UTC (Thu)
by Tara_Li (guest, #26706)
[Link] (26 responses)
Posted Feb 14, 2013 22:45 UTC (Thu)
by arjan (subscriber, #36785)
[Link] (23 responses)
Posted Feb 14, 2013 22:55 UTC (Thu)
by tglx (subscriber, #31301)
[Link] (21 responses)
Posted Feb 14, 2013 23:21 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (20 responses)
Posted Feb 15, 2013 1:56 UTC (Fri)
by mmarq (guest, #2332)
[Link] (15 responses)
Doubt anyone could do any useful work while they are walking, so the ultre-thin ultra-book concept makes much more sense...specially if by some way you could hook a mobile phone (anyone call it what they like) and softphone anywhere(which is only one functionality possible).
Posted Feb 15, 2013 9:51 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (4 responses)
Posted Feb 15, 2013 14:30 UTC (Fri)
by pboddie (guest, #50784)
[Link]
Posted Feb 18, 2013 13:25 UTC (Mon)
by ibukanov (subscriber, #3942)
[Link] (1 responses)
As a big bonus the complexity of software on the phone is much less than what is available on a typical smartphone so I can trust it more.
Posted Feb 19, 2013 18:59 UTC (Tue)
by man_ls (guest, #15091)
[Link]
Posted Feb 21, 2013 1:22 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
[1]http://ipadpockettees.com/
Posted Feb 15, 2013 12:55 UTC (Fri)
by drag (guest, #31333)
[Link] (9 responses)
* Take decent photos.
* find stores. Find store times. Find phone numbers. Look up prices while at store to see if it's a good deal or not. See review of products. Look up technical information when buying computer parts.
* Keeping track of phone numbers.
* Be able to communication with a number of people via their favorite method. Some people are most easily reached via text message as they don't answer their phones usually. Some people prefer to get stuff via email. etc.
* Calenders. Reminders. Notifications.
* Maps and other things for determining speed, direction, location, etc.
* Looking up how to do something. If your in the midst of working on your car, plumbing, heart surgery, or whatever then you can easily find videos, howtos, and guides for most anything quickly.
* playing videos games. Playing card games with others. reading stuff. Watching videos, movies, television shows, listening to the radio, listening to online radio, listening to mp3s, listening to streaming mp3s, podcasts, books, newspapers, magazines, etc.
* Being able to be easily reached at any place. Easily being able to disable being easily reached at any place.
Generally speaking they are pretty awesome. Ultimate use of functionality depends on how often you are out and about.
However honestly?
Most people buying them probably do it to do email, facebook, and surf the web while at work since most businesses do quite a bit of filtering to prevent virus infections at work and other issues.
Posted Feb 15, 2013 18:34 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Feb 18, 2013 13:33 UTC (Mon)
by nye (subscriber, #51576)
[Link]
I submit that this is largely selection/confirmation bias.
There are at least a couple of *billion* people with smartphones, the majority of whom are entirely non-technical and have no trouble using one as a phone. If the situation were even remotely as bad as you suggest, it would be very obvious.
Posted Feb 15, 2013 19:48 UTC (Fri)
by Lennie (subscriber, #49641)
[Link] (5 responses)
Posted Feb 16, 2013 3:42 UTC (Sat)
by hummassa (subscriber, #307)
[Link]
Posted Feb 18, 2013 13:49 UTC (Mon)
by nye (subscriber, #51576)
[Link] (3 responses)
Battery life if obviously a trade-off against what you want to do. If you want to do those things, it's not reasonable to expect that battery life will not be reduced.
(To take the argument ad absurdum, I could suggest that it's stupid to have a mobile phone at all when a landline never needs charging, but almost everyone acknowledges that having the extra mobility in exchange for the necessity of charging batteries is a worthwhile trade-off.)
If you literally never need any of those facilities, then of course a smartphone is a bad choice; that shouldn't even need saying.
If you *might occasionally* need them but don't use them in the normal course of events, the battery life is likely to be on the same order as a dumbphone. It will be less, to be sure, but not ten times less - you might be looking at around a week versus two weeks. The reason a smartphone's battery life is typically less in practice is that it turns out people want and use those features.
This isn't theoretical BTW; on some very rare occasions I've left my phone largely unused for a week or more and not had the battery run out, and it's an HTC Desire which is now pretty long in the tooth and wasn't particularly known for its stellar battery life even new.
(Random addendum: the real battery-killer is of course travelling, as the phone desperately tries to find a connection presumably by boosting its output power, then has to do it all over again 30 seconds later. Back when I had a non-smart mobile phone, it would have a battery life of around two weeks, or three hours on a train, which is a bit of a bugger really. Things don't seem to have improved much in that department.)
Posted Feb 21, 2013 1:45 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Feb 21, 2013 11:54 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
Posted Feb 22, 2013 3:51 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Feb 19, 2013 19:07 UTC (Tue)
by man_ls (guest, #15091)
[Link]
Posted Feb 16, 2013 3:21 UTC (Sat)
by idupree (guest, #71169)
[Link] (3 responses)
Posted Feb 18, 2013 13:33 UTC (Mon)
by ibukanov (subscriber, #3942)
[Link] (2 responses)
Insecure in what sense? A typical application on Windows/Mac/Linux PC can read/change all my data, but this is not so on Android. The only advantage of a PC AFAICS is the hardware visualization so OS can run wireless and other complex drivers isolated from the rest of the system. But such advantage is mostly theoretical as very few PC utilizes that.
Posted Feb 21, 2013 3:59 UTC (Thu)
by draco (subscriber, #1792)
[Link] (1 responses)
Posted Feb 21, 2013 10:20 UTC (Thu)
by hummassa (subscriber, #307)
[Link]
Posted Feb 21, 2013 20:09 UTC (Thu)
by jldugger (guest, #57576)
[Link]
Posted Feb 14, 2013 23:02 UTC (Thu)
by ovitters (guest, #27950)
[Link]
Posted Feb 14, 2013 23:22 UTC (Thu)
by mricon (subscriber, #59252)
[Link]
Posted Feb 14, 2013 23:40 UTC (Thu)
by binkert (guest, #87008)
[Link] (2 responses)
Posted Feb 15, 2013 2:09 UTC (Fri)
by mattdm (subscriber, #18)
[Link] (1 responses)
Posted Feb 15, 2013 3:11 UTC (Fri)
by binkert (guest, #87008)
[Link]
Posted Feb 15, 2013 0:11 UTC (Fri)
by spender (guest, #23067)
[Link] (37 responses)
An attacker will have a hard time escaping the SELinux jail on your browser? The browser with JIT? The browser that can save files that the user can execute? The browser that downloads open-source software from sites that have been trojaned? The user that can ptrace his own processes? The user that can modify his own .bashrc? The user that can add a line to his .bashrc to present a trojaned bash to the user? That can present a fake password/two-factor prompt and just pass on the credentials invisibly?
Default SELinux policies aren't going to do anything. If a policy is as generic enough for everyone's individual use-cases, it's weak enough for the user to shoot himself in the foot. Your generic distro kernels also have a nice huge attack surface. An attacker can prepare for all of these things in advance for a pretty one-shot: your kernel is public, your policies are public.
Always execute ssh with the full path because your $PATH can't be trusted? If your $PATH can't be trusted, you will have more problems than executing ssh as /usr/bin/ssh will solve.
Keep on believing! This SELinux/two-factor religion will surely pay off. It's no wonder you can't secure your systems.
-Brad
Posted Feb 15, 2013 2:01 UTC (Fri)
by pspinler (subscriber, #2922)
[Link] (36 responses)
If so, I disagree, at least a bit. I believe that security is never an absolute, but is best implemented as many layers and steps, sometimes even trivial ones.
I'm never going to be completely secure no matter what I do, but if I can make myself _more_ secure, even just a little, well then I think it's at least worth a cost (convenience) / benefit (security) analysis.
-- Pat
Posted Feb 15, 2013 2:38 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (35 responses)
Posted Feb 15, 2013 3:08 UTC (Fri)
by mricon (subscriber, #59252)
[Link] (34 responses)
Yes, many of the steps can be defeated by a dedicated attacker, but they will make a casual attacker's life more difficult. Saying "if a given measure, no matter how complex/simple, does not solve a problem then well, you're not better off doing it" is shortsighted. It's like saying "bulletproof vests can be defeated if the attacker aims at the head, therefore why bother." It takes a lot more effort to aim and hit the head. Similarly, typing in /usr/bin/ssh will only make your life harder by 8 characters, while an attacker would have to put in place a trojaned version of bash to defeat it instead of a simple wrapper script.
In any case of a user-level compromise, it's only a matter of time before the attacker gets into your servers -- whether you use 2-factor authentication, SELinux, or any other kind of security technology at all. The difference is how quickly it will happen and how difficult such a task would be to an attacker. 2-factor authentication adds another layer that must be defeated, and hopefully this will buy you enough time to notice something odd going on.
Posted Feb 15, 2013 3:58 UTC (Fri)
by spender (guest, #23067)
[Link] (33 responses)
Like this:
I'm sure you didn't know Fedora allows over 20 roles access to these devices. With only uid 0 (no capabilities), not even modules_disabled or /dev/mem restrictions can prevent the kernel from being easily rootkitted. None of your distros cared to assign a CVE even while I said I had exploit code for it until after I released it.
-Brad
Posted Feb 15, 2013 8:50 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (32 responses)
Surely with a market penetration of Linux these days, there should be money around to do such a thing...
Posted Feb 15, 2013 10:10 UTC (Fri)
by imitev (guest, #60045)
[Link] (31 responses)
For instance I had never heard of Atomic Secured Linux, one of the products of grsecurity's sponsors, but after googling a little bit quite a few companies seem to use it and it looks interesting enough that it's now on my ever growing list of things to test/deploy.
As for pushing things in the kernel it seems you missed the animosity between spender and some prominent kernel devs, who (in his opinion) never label bugs as security ones and almost always tend to favor performance over security.
Posted Feb 15, 2013 10:33 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (30 responses)
When people meet face to face at some conference where such issues are discussed, it is hard to ignore a real person in front of you making a valid point. No matter which "side" they are on.
Posted Feb 15, 2013 16:02 UTC (Fri)
by adobriyan (subscriber, #30858)
[Link] (29 responses)
Posted Feb 15, 2013 18:44 UTC (Fri)
by nix (subscriber, #2304)
[Link] (28 responses)
I note that this behiaviour persists despite some of these people being pseudonymous. Before running into these people I would have assumed that credit-hungry pseudonymous people were a contradiction in terms. Now I know that is not true.
Posted Feb 15, 2013 19:37 UTC (Fri)
by spender (guest, #23067)
[Link] (20 responses)
This is the great thing about open source software -- if you don't like me, you're free to do my work yourself or get the same work from someone else.
Except for that little minor detail that the former will never happen and the latter doesn't exist. Like it or not, we're the only ones that care enough to have spent over a decade on the large security problems, despite the generally unappreciative Linux userbase.
We will continue to do worthwhile work while criticizing from the outside; I'm sure you'll likewise continue to complain about the way in which free code is given to you without accomplishing anything constructive in the process.
My responsibility is only to my own users. If you feel so strongly about this issue, why don't you spend all your free time like I do to do something about it other than complain?
Thanks,
Posted Feb 15, 2013 19:57 UTC (Fri)
by patrick_g (subscriber, #44470)
[Link] (19 responses)
It could be much more useful if you try to integrate mainline. At the moment very few people are using Grsecurity kernels. If you accept some compromises and try to work with other kernel hackers, your valuable work will be used by millions and millions of people.
Posted Feb 16, 2013 1:37 UTC (Sat)
by bojan (subscriber, #14302)
[Link] (18 responses)
Brad,
Trading insults on LWN may be fun, but given than you seem to care about security, open source, Linux kernel and users, doing the above would be a lot more useful. I would surely appreciate knowing that my latest stock kernel of my fav distros is as good as it can possibly be security wise.
Unfortunately, you should not expect that everyone's a genius when it comes to security. Most people are average or thereabouts, yours truly included. If I was able to get my shitty contribution into kernel proper, I am sure it should be possible for you as well. Patience, will to compromise and listening to points of view of others will be required, however.
Posted Feb 16, 2013 23:08 UTC (Sat)
by spender (guest, #23067)
[Link] (17 responses)
Read those first. This is the post I'll link to for similar questions in the future.
People who suggest what patrick_g have suggested are generally ignorant of our history and what we've done, and honestly I find the constant suggestions (even if good-intentioned) from people who don't contribute to furthering security or to our project in any way pretty tiresome and rude.
Both the PaX Team and myself do this work in our own free time. It already uses up more of my time than I'm comfortable with. Where do you propose this additional time come from to do the things you suggest? Take note that that additional time isn't a one-time cost, it would be a cost any time we want to push any additions or changes. It would still be a cost to us every time the kernel is updated. If you think otherwise, ask who is currently ensuring that kptr_restrict in the upstream kernel does what it claims?
The only work that interests me is dealing with the unsolved, difficult security problems. I don't want to spend my time playing politics. I paid out of my own pocket in 2010 to attend the Linux Security Summit and present on what the current state of security was in grsecurity and suggesting ways Linux could harden the kernel in the next decade (judging by how long it takes to rip off our features). Do you know how many major kernel developers attended the summit? None! They were all busy in their own non-security subgroups. It was overall an SELinux circlejerk and a waste of time (other than convincing Kees Cook apparently).
What has been suggested was already attempted by Vasiliy Kulikov during the 2011 GSOC. Here were the results:
Dan Rosenberg got Openwall's dmesg restriction merged upstream and attempted to get grsecurity's HIDESYM feature merged upstream. While the dmesg feature is complete (not difficult as it's only a single line of code basically) the HIDESYM feature is woefully incomplete and thus quite useless. None of the kernel developers nor Dan himself care to update it so that it does what it claims.
Seriously, this is all! How much time was wasted on all this? Over 600 emails were ultimately sent on the kernel-hardening list alone for this:
What have other people done in this area? Ubuntu's kernel hardening roadmap is nearly completely Openwall/grsecurity ripoffs:
In September, 2012 a "Linux security workgroup" was formed:
I don't believe in wasting time on these top-down exercises, where we build some organization or framework with the expectation that the actual useful people or code will just fall into place. It's almost always a failure. Instead I've put my focus on actually creating things. During the same timeframe as above (2011 to now), what have I alone accomplished?
See http://grsecurity.net/the_case_for_grsecurity.pdf slide 15 onward
Bruteforce deterrence for suid/sgid binaries
We'd need a couple more pages to list what the PaX Team has accomplished in the same time-frame. The "toolchain support" section of http://pax.grsecurity.net/docs/PaXTeam-LATINOWARE12-PaX-l...
Now that the general ignorance has been laid bare, do you really want to demand that I waste the time I currently spend creating the above and put it toward fighting with Linus and others to get a measly percentage of these previous improvements merged upstream? It's telling really that on this site, people want to complain to or insult the messenger instead of asking questions and learning something about how security can be improved.
In 2008, we made the case (and proved really, it's not up for debate at this point) that the upstream developers were intentionally covering up security vulnerabilities and that this was harmful for Linux as a whole. The overwhelming response to Linus covering up security vulnerabilities was: "Yes, and?".
In recent news, this has screwed over Linux users yet again with the publication of CVE-2013-0871: http://seclists.org/oss-sec/2013/q1/326. The vulnerability was reported to security@ last month and yet across the board there is not a single vendor report or fix. This despite a Red Hat employee committing the fix. I however spotted the fix last month and backported it, as it matched the model I joked about in my H2HC presentation as a way to find silent upstream vuln fixes. Solar Designer's comments in the reply raise some serious questions that people should be asking. If history is any judge, though, they won't, and the status-quo will continue.
The majority of Linux users apparently are happy with the constant cycle of updates, bugfixing as the way to security, the "a bug is a bug" mantra, the appeal-to-authority SELinux, and other associated snake-oil and bad security advice. I'm no longer interested in helping these people; I believe in a security meritocracy. I'm not going to change the minds of users in general who aren't receptive to new ideas. For them, there's an entire parasitic security industry of AV/IDS/IPS/"Cloud" vendors who would be happy to take their money and make them feel good about it.
As I said before, this problem is not about us: it's about you and the rest of the Linux community. What are you doing to push for change from the status-quo? What are you doing to improve security and how it's handled? What are you doing to extend our work? What are you doing to support our work and make our efforts easier?
-Brad
Posted Feb 17, 2013 20:45 UTC (Sun)
by bojan (subscriber, #14302)
[Link] (16 responses)
You keep repeating the history. The only thing this will tell you is what not to do. It is otherwise mostly irrelevant. Also, as a side note, pointing fingers and blaming people (especially saying that everything is 100% someone else's fault in an argument) is simply counter productive.
Now to the real issue. You ask:
> Both the PaX Team and myself do this work in our own free time. It already uses up more of my time than I'm comfortable with. Where do you propose this additional time come from to do the things you suggest?
I propose you spend none of your free time on this. Zero. I propose you get paid to do this. And well.
Linux is a multi billion dollar business. If you can show to any of the companies that are involved (Google, Red Hat, Oracle, Samsung, etc.) that they can sell what you have, they will buy it.
So, in a nutshell: you need to sell it.
Doing things the old "I'm a volunteer who pays my own way to a conference" way isn't going to do it. You should stop fighting "them" and become one of "them" - and get paid for it.
So, when you rock up at a conference (at company expense) and present your work (which has been shipping in a supported product people paid money for), others may listen more closely.
At least there is no downside for you - you would get paid doing what you obviously love doing anyway. And you would have a greater number of users who appreciate your work.
Posted Feb 18, 2013 3:48 UTC (Mon)
by clopez (guest, #66009)
[Link] (15 responses)
What strikes me is why Spender was unable yet to get a well-paid full-time job for hacking on grsecurity.
Isn't any of the big Linux distributions focused on the server market (RedHat/SUSE/Oracle/Ubuntu..) interested in shipping hardened kernels? Aren't their customers demanding this? Why?
Is just because they think that with the linux LSMs (SELinux/Apparmor/etc..) is enough?
Posted Feb 18, 2013 6:10 UTC (Mon)
by px43 (guest, #89407)
[Link] (6 responses)
Posted Feb 18, 2013 6:26 UTC (Mon)
by dlang (guest, #313)
[Link] (4 responses)
Umm, Linus does work on Linux as his full-time paid job, he has for quite a few years.
He avoided working at any distro, but he is one of several people who are paid by the Linux Foundation to work on Linux full-time.
creating fixes that almost nobody runs isn't a very effective thing to be doing. if they produced 1/10 as many fixes, but those fixes got into the upstream kernel their effect on the world would be much larger.
The problem is that they want to just say "security says we need to do this" and have whatever they have provided accepted.
the kernel people want to understand what the problem is, look at the impact of doing things, and try to find a solution that both solves the problem and doesn't hurt performance. That's not what Spender and Paxteam want, they seem to want people to accept and run whatever they provide.
There are other developers who work this way, and a few of them do have an impact (Theo, djb, and Jörg Schilling are three examples), but they end up fading from relevance over time as other people who work better with others are more effective.
Posted Feb 18, 2013 7:32 UTC (Mon)
by imitev (guest, #60045)
[Link] (3 responses)
My feeling with kernel security is that performance and compatibility with broken stuff gets the priority over security. LWN's fine editors have been outlining the lack of focus on security - albeit with diplomacy and subtlety - for quite some time, so it's not just me.
grsecurity is GPL, so the personality of developers isn't relevant: whatever they think of Spender's behavior, any of the kernel people you mention could rip and push gresecurity solutions/concepts upstream. But this doesn't happen. So 1/ either kernel people who have enough "power" to push for such changes are not interested in security, or 2/ they won't look at spender's work just because they don't like him, or 3/ grsecurity features are useless. Kernel devs are not in kindergarten and if we assume that security-conscious companies who use grsecurity know what they are doing, that leaves us with 1/
Posted Feb 18, 2013 7:56 UTC (Mon)
by dlang (guest, #313)
[Link]
And as part of the application, he would need to show that he can work with the community, which would be a fairly hard thing to do given his current attitude
Posted Feb 18, 2013 8:06 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
They are also far too busy reviewing and accepting code where the author wants it to be part of the kernel to go hunting around for code that may exist, may or may not have bugs, may or may not apply to the core kernel without problems, and may or may not even be legally released.
one of the side effects of the SCO fiasco is that they require that people attest that they have the right to contribute the code that they submit. Just saying 'someone slapped a GPL tag on it' isn't going to be good enough
The kernel developers have removed code that they had the legal right to include in the kernel because the author of the code wanted them to. They aren't about to go hunting for code who's author may oppose what they do with it.
Posted Feb 18, 2013 10:20 UTC (Mon)
by imitev (guest, #60045)
[Link]
Well the *class* of exploits that grsecurity prevents looks rather practical to me (and if it was only theoretical why would security companies even bother using it?), so we'll have to agree to disagree.
> The kernel developers have removed code that they had the legal right to include in the kernel because the author of the code wanted them to.
Code != concepts. So OK, the problem is then with patents.
> Well, he would have to make a case that he needed to be paid by them
I don't understand how your comment relates to what I've written.
Posted Feb 18, 2013 7:15 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
If that were the case, the obvious move would be for the Linux Foundation to pay him a stipend just like they're paying Linus.
Posted Feb 18, 2013 6:18 UTC (Mon)
by treed (guest, #11432)
[Link] (6 responses)
Posted Feb 18, 2013 13:41 UTC (Mon)
by dpquigl (guest, #52852)
[Link] (5 responses)
All that being said Spender and PaXTeam do tons of great work. I would love to see a lot of their code merged into mainline but the likelyhood of that happening isn't very good. If you use a Hardened Gentoo kernel you'll actually get a kernel with PaX protections with some GRSecurity features and SELinux enabled which I think is an awesome thing. As Spender showcased above he does not play politics or suffer fools. What he doesn't seem to care about is that most of the kernel inclusion process is politics. We've seen it before with competing implementations of features where the person in the "in crowd" got their implementation chosen over someone who had been working on the problem for a very long time with a large user base. That coupled with a hostile attitude from upstream about security (Linus has repeatedly called security people crazy, Spender and SELinux people included) makes it hard to dedicate time to working on getting things upstreamed.
Posted Feb 18, 2013 13:57 UTC (Mon)
by dpquigl (guest, #52852)
[Link] (4 responses)
Posted Feb 18, 2013 14:01 UTC (Mon)
by spender (guest, #23067)
[Link] (3 responses)
Posted Feb 18, 2013 14:03 UTC (Mon)
by dpquigl (guest, #52852)
[Link] (2 responses)
Posted Feb 18, 2013 15:21 UTC (Mon)
by spender (guest, #23067)
[Link] (1 responses)
-Brad
Posted Feb 18, 2013 15:45 UTC (Mon)
by dpquigl (guest, #52852)
[Link]
Posted Feb 18, 2013 13:50 UTC (Mon)
by dpquigl (guest, #52852)
[Link]
Posted Feb 15, 2013 19:51 UTC (Fri)
by spender (guest, #23067)
[Link] (6 responses)
I've also decided that I will dedicate to you my upcoming ARM blog, a weighty 3000+ word article on how I implemented proper kernel memory permissions and user/kernel address space separation on ARMv6+.
Thanks again for all your hard work, and may the rest of your day be as pleasant as you!
Sincerely,
Posted Feb 15, 2013 23:36 UTC (Fri)
by ssmith32 (subscriber, #72404)
[Link] (4 responses)
You flame the list, make absolutely no useful, constructive suggestions, then proceed make some long walk-around-the-park sarcastic remark about another user.. and then finally link to a collection of comments you curate that describe what a jerk some people say you are?
The last was the part that made me smile.. picturing a guy with his treasured list of "bad things nix said about me today" tucked away in a drawer, crooning over it... "my precious..."
I suppose I'm missing some history here.. you could be a great guy and all in real life, but on the face of it, that is.. so... weirdly anti-social.
Like I said I guess I missed something, but, can't figure out what..
But seriously.. if you don't like the linux people or respect the work or even use the software, why do you bother with it? If you don't like collaboration, why not take djb approach and just write your own kernel? I mean he's a difficult guy too, but he ends up making useful contributions that way.
I'm not the best programmer, I'm sure you could hack the crap out of me, and I struggle with people at time too.. but I do try to make sure I make a positive, constructive contribution to the world at the end of the day..
Take care,
Posted Feb 16, 2013 0:11 UTC (Sat)
by spender (guest, #23067)
[Link]
Let me know when you've made that positive constructive contribution for today.
-Brad
Posted Feb 16, 2013 3:39 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
However, nix's arguments about spender's attitude are spot on.
Posted Feb 22, 2013 12:51 UTC (Fri)
by ortalo (guest, #4654)
[Link]
We need to break that dichotomy between "users are not interested in security - look I can break their system any day in 2012" and "they found a DoS on my personal worthless phone and want me to stop me from making calls for business for one year - theses security guys are ivory tower idiots". (Note how both statements are equally stupid.)
That dichotomy *is* a problem. Maybe it has been maintained for a long time by people taking advantage of it for their own interest (such as writing reports about how long that single bug took to fix in the kernel, or grabbing budgets for entirely unsecure e-voting machines and other miscellaneous devices).
Stated differently, the day we will say "that performance/usability vs. security debate is over, we know how to decide and agree on such questions (without forking entirely different systems)" - that day we will be able to claim higher security than proprietary systems. And that's doable.
Posted Feb 25, 2013 17:29 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Feb 25, 2013 17:31 UTC (Mon)
by nix (subscriber, #2304)
[Link]
It is beyond me to see why anyone would value such a thing. (But then, I spent a huge proportion of my time over the past thirty-plus years attempting to become less abrasive and socially uncomprehending: I guess that makes it hard for me to see why attempting to make people dislike you could be considered a *good* thing.)
Posted Feb 15, 2013 14:57 UTC (Fri)
by southey (guest, #9466)
[Link] (2 responses)
The most basic problem is that cells signals have a very hard time passing into buildings. The second basic problem is that data and text plans are not free for the user (even ignoring the cost of said phone) and probably not for the provider that has to send that information. So I do not see employers paying for things needed for cell phone to access the workstation. That is totally ignoring that phones are not secure for most obvious reasons. Phones are just another item that can be lost, stolen or broken and numbers can change. Also can be eavesdropped or jammed for the more dedicated attacks. Finally you also think that the phone is actually secure - maybe the US President's is. Smartphones also run web-browsers and can full of games and other apps that like to talk to the world whether you want it or not. Further, you probably monitor the security of the workstation more than your smartphone.
Posted Feb 15, 2013 15:52 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
The smartphone in this scenario is not being used for its capability as a phone or cellular device. Its role is as a compute device with a user interface, that most people already own‡ and which isn't directly connected to the user's workstation.
This means it doesn't matter if the user pays for data, text, whatever. In fact it doesn't matter if it's not actually a _phone_ at all, for example the "iPod touch" is basically an iPhone with no cellular capability and that's just fine for this sort of thing.
And further it's not really important that it's a "smartphone". The compute workload involved is very modest, a Java MIDP phone (the sort of thing given away in developed countries even with "Pay as You Go" service) is quite capable of doing the work, but obviously the user interface in this case is restricted by the phone's physical capabilities.
The reason to use the phone is, as I touched on above, because it's independent of the user's computer. In Brad's world, where every script kiddie is using heavily customised attacks developed for them (presumably for free?) by geniuses this buys you nothing, the attacker "simply" identifies the user's phone, breaks into that, and gets the credentials.
In the real world where most of us live, this is one more step that ordinary unsophisticated attackers won't get past. One script kiddie breaks into a phone, a different script kiddie gets a password, and they never connect these two things to make a working attack. I actually get a pretty good view onto what these people are up to as a side effect of my job and they're barely capable of de-URI-encoding a string they found in a database let alone smushing data sets or using metadata to connect together records with no immediate relationship.
‡ and, they're used to carrying them about and will notice if it gets "lost" somewhere.
Posted Feb 15, 2013 16:32 UTC (Fri)
by mricon (subscriber, #59252)
[Link]
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
I am quite excited about this progress as my company is currently relying on a physical proprietary two-factor solution which is expensive, has several shortcomings and a dodgy record. Using a regular smartphone might not be secure enough for our environment but it could be possible that buying in cheap, very locked down smartphones/computers for this sole purpose, could be a viable and much cheaper solution in the near future.
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
The functionality I want is "being able to carry Wikipedia and Google Maps in my trouser pocket". Your ultrabook doesn't even appear on the radar.
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
On the radar
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
In case you did not notice: what you are carrying around is called a smartphone. Yes, even primitive Symbian devices were smartphones. They are not defined by the big screens or the short battery life, but by having a general purpose OS with the ability to load user programs.
Also a smartphone
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
[2]http://news.tacticalpants.com/the-perfect-ipad-2-pants-po...
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
* Be able to communication with a number of people via their favorite method.
... as long as that method isn't a phone call. I've avoided smartphones like the plague myself, but every single one of my telephonic correspondents who has a smartphone (even the highly technical ones) has terrible trouble actually getting it to work as a phone. Some of them crash in the middle of calls or when getting cut off and require rebooting: some of them require rebooting whenever you associate a Bluetooth headset: some of them just have really really bad call quality. Not one appears to be tolerable. This seems to be a universal across iPhone and Android: I don't know anyone with a Windows Phone to judge, but I suspect that sucks too. (Curiously, BlackBerries, at least before the latest revision, were not too incompetent at being a simple phone.)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
Bacteria on cellphones
Looking up how to do something. If your in the midst of working on your car, plumbing, heart surgery, or whatever then you can easily find videos, howtos, and guides for most anything quickly.
Just in case some real doctors just came out from hibernation, are reading this and planning to take their cellphones to their next operation: many bacteria are found in cellphones, including methicillin resistant Staphylococcus aureus. For the rest of you: wash your hands after fondling your smartphone and before doing the same to your closest ones, or cooking dinner. They are filthy!
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
http://grsecurity.net/~spender/msr32.c
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
So yes, it seems companies already employ/sponsor Spender, and with the increasing coverage of cyber "threats" seen lately in high traffic news sites, I hope we'll get a welcome focus on security.
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
-Brad
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
https://lwn.net/Articles/315164/
http://unix.stackexchange.com/questions/59020/why-are-the...
http://openwall.info/wiki/Owl/kernel-hardening
What got merged upstream as a result of this?
A variant of /proc restrictions from Openwall and grsec (but without my additional changes).
Openwall's HARDEN_SHM as an optional sysctl.
http://www.openwall.com/lists/kernel-hardening/
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening
It hasn't been updated in nearly a year, unsurprisingly not long after Kees Cook left Canonical for Google.
http://www.openwall.com/lists/kernel-hardening/2012/09/24/1
They have yet to accomplish anything AFAIK.
Preventing module auto-loading by unprivileged users
Enforcing that only filesystem modules can be loaded via mount
Banning an unprivileged user until reboot if he/she causes a detected kernel corruption
Whitelisting specific slab caches when doing copies between userland and the kernel. A copy_from_user could not be abused, for instance, to perform a copy directly into a task struct now.
Disallowed ptracing unreadable binaries
A multithreaded app's change from uid 0 to non-0 will be shared among all threads. Glibc already does this in userland, but other libcs/languages do not.
Race-free implementation of Apache's SymlinksIfOwnerMatch
Prevented suid apps from being able to have alternate memory layouts
Reduced ability to lessen stack entropy for suid apps
Implemented a special ID to protect various /proc entries against future /proc/pid/mem-style vulnerabilities
Automatically protected /proc entries and other seq_file users against kernel address leakage.
Prevented infoleaking of write timings against block/character devices
Killed reliable technique of overwriting another thread's userland stack due to distros not enabling -fstack-check on network services
Protected the BPF JIT against use for in-kernel arbitrary code execution
Implemented PXN support on ARM with VMSAv7, LPAE on or off
Implemented PAX_KERNEXEC on ARM LPAE
Implemented PAX_KERNEXEC/PAX_UDEREF on ARMv6+
lists just some of these.
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
Let's have a look at virtualization: one would think that it's a patent minefield compared to security, but we continue to enjoy a steady rate of improvements and new features in that area. Maybe it's just that it's more fun and interesting to develop than security. Or not: companies make money selling virtualization products, or save money buying them to optimize their computing resources. Meanwhile, security is not only costly, with no immediate benefits, but it also prevents your employees from getting the work done in a quick&dirty way, it makes users yell at sysadmins, and a few other dozen complaints. You just realize how nice it would have been when your systems are compromised. And on the other side, if you invested in it, you might not see any effect since you effectively decreased the chance somebody would manage to hack you. I'm wandering too far, but the point is that security is a difficult sell, I don't think it has anything to do with legal stuff. People are just not interested.
There seems to be an assumption that Spender needs money and should be paid to push features upstream; I hope for him he's already well paid between sponsoring, consulting, and (maybe) selling exploits. I anticipate you'll ask why he's then bothering trying to advertise his superior features, maybe he's just trying to prove a point and have some recognition for the work he's doing - very human, after all. Granted, with a complete lack of diplomacy.
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
I'm pretty sure spender doesn't work on grsec professionally for the same reason that Linus doesn't work on Linux professionally. If he had to declare loyalty to one company, it would create a conflict of interest.
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
http://www.h2hc.com.br/h2hc/pt/palestrantes#Speaker2
-Brad
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
-stu
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
It has also been maintained by some of our short sightedness. We are culprit of not having studied enough the reasons for the existing disagrement on the level of necessary computer security mechanism in our systems, it deserves more studying.
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
How The Linux Foundation and Fedora are Addressing Workstation Security (Linux.com)
Who's paying?
Who's paying?
Who's paying?