Re: NFS4 authentification / fsuid
Hi Valdis, On Wed, 19 Sep 2007, [EMAIL PROTECTED] wrote: > > On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said: > > > I am assuming that if the laptop has sufficiently important data on > > it to warrant the above steps then I am also clueful enough to: > >(A) Not carry the laptop around unsecured areas, > >(B) Keep a close enough eye on it and be aware that it's gone by > > the time they get to step 2, OR > >(C) Pay somebody to build me a better physical chassis for my laptop > > Building a better chassis can be a challenge when the threat model really > *does* include attacks by a well-funded TLA. > > http://www.epic.org/crypto/scarfo/murch_aff.pdf Thanks for the link! And this was ... 1999 (!) Probably goes without saying that physical hacking tricks have only become even more refined/ perfected by now :-) > The FBI did an *initial* entry to survey the hardware, and then a total of > *five* other entries before they actually installed it. Note the technical > and legal requirements required on the KLS (it had to, among other things, > capture PGP passphrases but *not* anything that was typed online). Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007, J. Bruce Fields wrote: > > Uh, is there somebody else that feels they're being enlightened by this > discussion? Ok, probably I got a bit too harsh with Kyle there. But what I don't understand is why is it so hard for someone to accept they're wrong on this list, thank the other person and just move on ?! Even when you've explained an attack that wasn't considered, you've explained why the assumptions of the scheme were wrong, you've mentioned previous precedents, and *technically* refuted the other person's claims. Still, people feel obliged to *stick* to their (wrong) positions, subtly "shift" their argument (using new adjectives or qualifiers), whatever, just as long as they don't have to accept they were, simply, wrong. That just sucks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007, J. Bruce Fields wrote: Uh, is there somebody else that feels they're being enlightened by this discussion? Ok, probably I got a bit too harsh with Kyle there. But what I don't understand is why is it so hard for someone to accept they're wrong on this list, thank the other person and just move on ?! Even when you've explained an attack that wasn't considered, you've explained why the assumptions of the scheme were wrong, you've mentioned previous precedents, and *technically* refuted the other person's claims. Still, people feel obliged to *stick* to their (wrong) positions, subtly shift their argument (using new adjectives or qualifiers), whatever, just as long as they don't have to accept they were, simply, wrong. That just sucks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
Hi Valdis, On Wed, 19 Sep 2007, [EMAIL PROTECTED] wrote: On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said: I am assuming that if the laptop has sufficiently important data on it to warrant the above steps then I am also clueful enough to: (A) Not carry the laptop around unsecured areas, (B) Keep a close enough eye on it and be aware that it's gone by the time they get to step 2, OR (C) Pay somebody to build me a better physical chassis for my laptop Building a better chassis can be a challenge when the threat model really *does* include attacks by a well-funded TLA. http://www.epic.org/crypto/scarfo/murch_aff.pdf Thanks for the link! And this was ... 1999 (!) Probably goes without saying that physical hacking tricks have only become even more refined/ perfected by now :-) The FBI did an *initial* entry to survey the hardware, and then a total of *five* other entries before they actually installed it. Note the technical and legal requirements required on the KLS (it had to, among other things, capture PGP passphrases but *not* anything that was typed online). Thanks, Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said: > I am assuming that if the laptop has sufficiently important data on > it to warrant the above steps then I am also clueful enough to: >(A) Not carry the laptop around unsecured areas, >(B) Keep a close enough eye on it and be aware that it's gone by > the time they get to step 2, OR >(C) Pay somebody to build me a better physical chassis for my laptop Building a better chassis can be a challenge when the threat model really *does* include attacks by a well-funded TLA. http://www.epic.org/crypto/scarfo/murch_aff.pdf The FBI did an *initial* entry to survey the hardware, and then a total of *five* other entries before they actually installed it. Note the technical and legal requirements required on the KLS (it had to, among other things, capture PGP passphrases but *not* anything that was typed online). > Besides, if some government > wanted the data on your laptop that bad they'd just pick you up in > the middle of the night and torture your password out of you. See above. Though I *will* note that several years ago, a Department of Justice filing regarding the use of wiretaps and similar tools reported that in every single case that the FBI encountered encryption, it in fact didn't stop the FBI from getting the info it was looking for. Presumably, they either used Scarfo-type devices, or they rolled somebody for the key. They never *did* break Anthony Pellicano's PGP key, as far as I know pgpi6OjPorsKK.pgp Description: PGP signature
Re: NFS4 authentification / fsuid
On Wed, Sep 19, 2007 at 07:42:20PM +0530, Satyam Sharma wrote: > > > On Wed, 19 Sep 2007, Kyle Moffett wrote: > > > > > [all sorts of crap about spies in washington needing stronger protection > > > than your average consumer] > > > > [snip] > > > > [...] all the bullcrap about foreign intelligence > > Hehe, again, *you* started all the "bullcrap" about foreign "governments" > in the first place :-) Uh, is there somebody else that feels they're being enlightened by this discussion? --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007, Kyle Moffett wrote: > > > [all sorts of crap about spies in washington needing stronger protection > > than your average consumer] > > [snip] > > [...] all the bullcrap about foreign intelligence Hehe, again, *you* started all the "bullcrap" about foreign "governments" in the first place :-) > is just drawing > focus off of how easy it is to achieve *adequate* physical protection where it > matters. Ah, so you're qualifying the discussion with the nice and subjective "adequate" ... (you're still wrong, of course) > Of course, this also relies on being able to teach the stupid lusers with the > laptops not to give their boot password to the "service tech on the phone" Let's stick on-topic here ... remember "securing a system against attacker with physical access is fairly simple" ? [ Took the liberty of removing some irrelevant digressions -- didn't see any solid security scheme that fulfils/justifies your earlier claim over there. ] > > > If your system equates end-user with attacker > > > > "If"? Was there ever any doubt? > > > > Heh, did you even read the thread you just replied to? > > Yes I did [...] No, you didn't -- it was obvious from your reply :-) > and I wanted to make it *really* clear that with average hardware > you can properly protect against virtually all of the *common* attack vectors. ^^ But what gave you the impression we're interested in discussing "common" or "adequate enough" attack vectors here? See, if you have something useful/new to contribute to the discussion, that we don't already know, then please don't hold back and feel free to do so ... Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 19, 2007, at 08:16:30, Satyam Sharma wrote: [all sorts of crap about spies in washington needing stronger protection than your average consumer] Well no duh. I think most of the 4-year-olds I know could have told you that. What sense does it make to give a spy all sorts of fancy electronic listening and monitoring equipment and then rely on the physical security of your average Dell? You _can_ make a laptop sufficiently secure that its data is encrypted and it cannot be physically compromised to install a hardware keylogger without virtually destroying the enclosure, but that's completely unnecessary for 99.9% of the users on the planet. We would be much better off if all the companies getting their data stolen out from under them on company laptops would just use basic drive encryption and implement basic physical-security training. *THAT* is where protecting the laptop is easy; all the bullcrap about foreign intelligence is just drawing focus off of how easy it is to achieve *adequate* physical protection where it matters. From a practical standpoint, an identity thief trying to determine which company to attack will just steal a few laptops from a company which doesn't encrypt them instead of going through all the very risky steps of trying to break into the laptops of one that does. Of course, this also relies on being able to teach the stupid lusers with the laptops not to give their boot password to the "service tech on the phone" If your system equates end-user with attacker "If"? Was there ever any doubt? Heh, did you even read the thread you just replied to? Yes I did and I wanted to make it *really* clear that with average hardware you can properly protect against virtually all of the *common* attack vectors. The pretty standard problems of "somebody stole the company laptop with a bunch of credit-card info on it" or "my personal financial data was on the laptop I left in the airport", are pretty easy to make safe. Furthermore, that is *EXACTLY* the initial example I gave (my laptop with my personal data on it). On the other hand, I made this point in my original email, so if this is what you were arguing about you've been preaching to the choir. We're talking of consoles / hardware sold by commercial companies to users here, where they want explicitly want to prevent the users from being able to hack it. So yes, end user == attacker. then you are *screwed* regardless! Ah, finally you make my point again for me :-) To quote myself again: A fully self-certifying system that can prevent any attack is impossible to achieve. If I have the device and can devote as many hours as I want to breaking into it, there is exactly ZERO way to prevent that, aside from encrypting things and not giving out the key (which sorta makes it useless but is precisely the point of real crypto). There is a HUGE difference between "I don't want the end-user to hack into this" and "The end-user wants a certain degree of assurance that his data can't be compromised. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007, Kyle Moffett wrote: > > On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote: > > > > The whole *point* here is to secure against physical access -- then how can ^^^ > > you assume "barring disassembling the system"? If you're not considering > > attacks such as those, then how _are_ you solving the physical access > > problem in the first place? :-) > > [snip lots of totally irrelevant stuff] ??? What is your point, really? Let me repeat the situation: I own a computer (maybe portable one, such as a laptop) that I want to protect from attackers with physical access to my system. You're proposing a scheme that claims to secure it (against attackers with physical access) but assumes: "barring disassembling the system". Dude, looks like you're selling snake oil here. > > > Under this setup, tinkering with my BIOS does virtually nothing; the only > > > avenues of attack are strictly of the "Install a hardware keylogger" > > > variety. > > > > Doesn't flashing/replacing your BIOS firmware/chip count as tinkering? Then > > I don't really need a "hardware keylogger", do I ... > > Ok, so you are saying your plan of attack on this system would be: > 1) Steal the laptop such that I don't notice it has been stolen > 2) Open it up > 3) Replace the very-vendor-specific BIOS chip with a reflashed one with > sufficient storage to do all the things the old BIOS could *AND* have enough > storage for an entire replacement kernel binary with a built-in keylogger, as > well as some storage for the logged password > 4) Return the laptop, again such that I don't notice it has been missing > 5) Wait for me to boot and type my password > 6) Somehow recover the laptop *yet* *again* to get the password back off of > it and decrypt the disk Precisely. Do you think the above attack is "fantastical"? Wow, you're amazingly naive ... good luck ;-) [ See, if it's only your kid sister that you want to "protect" your 36GB worth of porn from, then you might as well use Windoze and one of those cute little "folder-locking" tool that we wrote back in 5th grade. However, if "hapless North Korean spy in Washington" describes you more accurately, then you better be ready for all sorts of attacks -- from exploding cigars [1], to poisoned ballpoint pens [2] :-) In short, you have no clue what you're talking about, and thankfully I'm not using any security software you had any part in designing :-) ] > Yes it "can be done", but so can dumping the firmware for an iPod out through > the built-in piezo clicker[1]. USE SOME COMMON SENSE HERE PEOPLE!!! The only > "unbreakable" computer is one always disconnected and off under armed guard in > a bank vault, and even then it's only as secure as the bank in which it is > stored (which get broken into on occasion). Thanks for repeatedly making *my* point :-) _You_ are the one who claimed protecting systems from attackers with physical access to be a "fairly simple" problem ... and here you're mentioning how *difficult* it is ... > I am assuming that if the laptop has sufficiently important data on it to > warrant the above steps then I am also clueful enough to: > (A) Not carry the laptop around unsecured areas, You might carry it home, might you not? What if your lover/girlfriend/wife is one of them? [3] > (B) Keep a close enough eye on it and be aware that it's gone by the time > they get to step 2, OR Hmm, you'd need to be a mutant to keep "close enough eyes" on your stuff while you're sleeping ... or drugged (?) > (C) Pay somebody to build me a better physical chassis for my laptop ROTFL ... these "workarounds" above are even more hilarious than your earlier "fairly simple" claim. > We are talking about *STANDARD* laptop systems with reasonably alert users. > If the user doesn't know how to properly protect the stuff on the laptop then > they probably don't know how to properly protect the other copy in their > heads, either. Dude, if the data in there is really that important, then better not store it on a computer / disk at all :-) > Besides, if some government wanted the data on your laptop > that bad they'd just pick you up in the middle of the night and torture your > password out of you. Surprisingly, you have (somewhat of) a point (!) > On Sep 18, 2007, at 19:48:16, Satyam Sharma wrote: > > On Fri, 7 Sep 2007, Kyle Moffett wrote: > > > So you can't draw any relationships between "Protect the end-user" with > > > "Protect the device FROM the end-user", the former can be done very > > > reliably to whatever level of risk-reduction you need and the latter can't > > > practically be done at all. > > > > Well, you're the one who called solving the physical access problem "easy" > > here ... :-) > > If your system equates end-user with attacker ^^ "If"? Was there ever any doubt? Heh, did you even read the thread you just replied to? We're
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007, Kyle Moffett wrote: On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote: The whole *point* here is to secure against physical access -- then how can ^^^ you assume barring disassembling the system? If you're not considering attacks such as those, then how _are_ you solving the physical access problem in the first place? :-) [snip lots of totally irrelevant stuff] ??? What is your point, really? Let me repeat the situation: I own a computer (maybe portable one, such as a laptop) that I want to protect from attackers with physical access to my system. You're proposing a scheme that claims to secure it (against attackers with physical access) but assumes: barring disassembling the system. Dude, looks like you're selling snake oil here. Under this setup, tinkering with my BIOS does virtually nothing; the only avenues of attack are strictly of the Install a hardware keylogger variety. Doesn't flashing/replacing your BIOS firmware/chip count as tinkering? Then I don't really need a hardware keylogger, do I ... Ok, so you are saying your plan of attack on this system would be: 1) Steal the laptop such that I don't notice it has been stolen 2) Open it up 3) Replace the very-vendor-specific BIOS chip with a reflashed one with sufficient storage to do all the things the old BIOS could *AND* have enough storage for an entire replacement kernel binary with a built-in keylogger, as well as some storage for the logged password 4) Return the laptop, again such that I don't notice it has been missing 5) Wait for me to boot and type my password 6) Somehow recover the laptop *yet* *again* to get the password back off of it and decrypt the disk Precisely. Do you think the above attack is fantastical? Wow, you're amazingly naive ... good luck ;-) [ See, if it's only your kid sister that you want to protect your 36GB worth of porn from, then you might as well use Windoze and one of those cute little folder-locking tool that we wrote back in 5th grade. However, if hapless North Korean spy in Washington describes you more accurately, then you better be ready for all sorts of attacks -- from exploding cigars [1], to poisoned ballpoint pens [2] :-) In short, you have no clue what you're talking about, and thankfully I'm not using any security software you had any part in designing :-) ] Yes it can be done, but so can dumping the firmware for an iPod out through the built-in piezo clicker[1]. USE SOME COMMON SENSE HERE PEOPLE!!! The only unbreakable computer is one always disconnected and off under armed guard in a bank vault, and even then it's only as secure as the bank in which it is stored (which get broken into on occasion). Thanks for repeatedly making *my* point :-) _You_ are the one who claimed protecting systems from attackers with physical access to be a fairly simple problem ... and here you're mentioning how *difficult* it is ... I am assuming that if the laptop has sufficiently important data on it to warrant the above steps then I am also clueful enough to: (A) Not carry the laptop around unsecured areas, You might carry it home, might you not? What if your lover/girlfriend/wife is one of them? [3] (B) Keep a close enough eye on it and be aware that it's gone by the time they get to step 2, OR Hmm, you'd need to be a mutant to keep close enough eyes on your stuff while you're sleeping ... or drugged (?) (C) Pay somebody to build me a better physical chassis for my laptop ROTFL ... these workarounds above are even more hilarious than your earlier fairly simple claim. We are talking about *STANDARD* laptop systems with reasonably alert users. If the user doesn't know how to properly protect the stuff on the laptop then they probably don't know how to properly protect the other copy in their heads, either. Dude, if the data in there is really that important, then better not store it on a computer / disk at all :-) Besides, if some government wanted the data on your laptop that bad they'd just pick you up in the middle of the night and torture your password out of you. Surprisingly, you have (somewhat of) a point (!) On Sep 18, 2007, at 19:48:16, Satyam Sharma wrote: On Fri, 7 Sep 2007, Kyle Moffett wrote: So you can't draw any relationships between Protect the end-user with Protect the device FROM the end-user, the former can be done very reliably to whatever level of risk-reduction you need and the latter can't practically be done at all. Well, you're the one who called solving the physical access problem easy here ... :-) If your system equates end-user with attacker ^^ If? Was there ever any doubt? Heh, did you even read the thread you just replied to? We're talking of consoles / hardware sold by commercial companies to users here, where they want explicitly want to prevent the
Re: NFS4 authentification / fsuid
On Sep 19, 2007, at 08:16:30, Satyam Sharma wrote: [all sorts of crap about spies in washington needing stronger protection than your average consumer] Well no duh. I think most of the 4-year-olds I know could have told you that. What sense does it make to give a spy all sorts of fancy electronic listening and monitoring equipment and then rely on the physical security of your average Dell? You _can_ make a laptop sufficiently secure that its data is encrypted and it cannot be physically compromised to install a hardware keylogger without virtually destroying the enclosure, but that's completely unnecessary for 99.9% of the users on the planet. We would be much better off if all the companies getting their data stolen out from under them on company laptops would just use basic drive encryption and implement basic physical-security training. *THAT* is where protecting the laptop is easy; all the bullcrap about foreign intelligence is just drawing focus off of how easy it is to achieve *adequate* physical protection where it matters. From a practical standpoint, an identity thief trying to determine which company to attack will just steal a few laptops from a company which doesn't encrypt them instead of going through all the very risky steps of trying to break into the laptops of one that does. Of course, this also relies on being able to teach the stupid lusers with the laptops not to give their boot password to the service tech on the phone If your system equates end-user with attacker If? Was there ever any doubt? Heh, did you even read the thread you just replied to? Yes I did and I wanted to make it *really* clear that with average hardware you can properly protect against virtually all of the *common* attack vectors. The pretty standard problems of somebody stole the company laptop with a bunch of credit-card info on it or my personal financial data was on the laptop I left in the airport, are pretty easy to make safe. Furthermore, that is *EXACTLY* the initial example I gave (my laptop with my personal data on it). On the other hand, I made this point in my original email, so if this is what you were arguing about you've been preaching to the choir. We're talking of consoles / hardware sold by commercial companies to users here, where they want explicitly want to prevent the users from being able to hack it. So yes, end user == attacker. then you are *screwed* regardless! Ah, finally you make my point again for me :-) To quote myself again: A fully self-certifying system that can prevent any attack is impossible to achieve. If I have the device and can devote as many hours as I want to breaking into it, there is exactly ZERO way to prevent that, aside from encrypting things and not giving out the key (which sorta makes it useless but is precisely the point of real crypto). There is a HUGE difference between I don't want the end-user to hack into this and The end-user wants a certain degree of assurance that his data can't be compromised. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007, Kyle Moffett wrote: [all sorts of crap about spies in washington needing stronger protection than your average consumer] [snip] [...] all the bullcrap about foreign intelligence Hehe, again, *you* started all the bullcrap about foreign governments in the first place :-) is just drawing focus off of how easy it is to achieve *adequate* physical protection where it matters. Ah, so you're qualifying the discussion with the nice and subjective adequate ... (you're still wrong, of course) Of course, this also relies on being able to teach the stupid lusers with the laptops not to give their boot password to the service tech on the phone Let's stick on-topic here ... remember securing a system against attacker with physical access is fairly simple ? [ Took the liberty of removing some irrelevant digressions -- didn't see any solid security scheme that fulfils/justifies your earlier claim over there. ] If your system equates end-user with attacker If? Was there ever any doubt? Heh, did you even read the thread you just replied to? Yes I did [...] No, you didn't -- it was obvious from your reply :-) and I wanted to make it *really* clear that with average hardware you can properly protect against virtually all of the *common* attack vectors. ^^ But what gave you the impression we're interested in discussing common or adequate enough attack vectors here? See, if you have something useful/new to contribute to the discussion, that we don't already know, then please don't hold back and feel free to do so ... Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, Sep 19, 2007 at 07:42:20PM +0530, Satyam Sharma wrote: On Wed, 19 Sep 2007, Kyle Moffett wrote: [all sorts of crap about spies in washington needing stronger protection than your average consumer] [snip] [...] all the bullcrap about foreign intelligence Hehe, again, *you* started all the bullcrap about foreign governments in the first place :-) Uh, is there somebody else that feels they're being enlightened by this discussion? --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Wed, 19 Sep 2007 01:16:28 EDT, Kyle Moffett said: I am assuming that if the laptop has sufficiently important data on it to warrant the above steps then I am also clueful enough to: (A) Not carry the laptop around unsecured areas, (B) Keep a close enough eye on it and be aware that it's gone by the time they get to step 2, OR (C) Pay somebody to build me a better physical chassis for my laptop Building a better chassis can be a challenge when the threat model really *does* include attacks by a well-funded TLA. http://www.epic.org/crypto/scarfo/murch_aff.pdf The FBI did an *initial* entry to survey the hardware, and then a total of *five* other entries before they actually installed it. Note the technical and legal requirements required on the KLS (it had to, among other things, capture PGP passphrases but *not* anything that was typed online). Besides, if some government wanted the data on your laptop that bad they'd just pick you up in the middle of the night and torture your password out of you. See above. Though I *will* note that several years ago, a Department of Justice filing regarding the use of wiretaps and similar tools reported that in every single case that the FBI encountered encryption, it in fact didn't stop the FBI from getting the info it was looking for. Presumably, they either used Scarfo-type devices, or they rolled somebody for the key. They never *did* break Anthony Pellicano's PGP key, as far as I know pgpi6OjPorsKK.pgp Description: PGP signature
Re: NFS4 authentification / fsuid
On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote: On Thu, 6 Sep 2007, Kyle Moffett wrote: On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: The question of how to protect against someone with *physical* access certainly is more difficult, but surely that's a separate problem. Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on- crypt-on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/ DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Umm, I did say "encrypt the root filesystem", didn't I? Booting my laptops The whole *point* here is to secure against physical access -- then how can you assume "barring disassembling the system"? If you're not considering attacks such as those, then how _are_ you solving the physical access problem in the first place? :-) Security is about fractional reduction of risk, and anybody who tells you otherwise is either ignorant or lying through their teeth. There are *multiple* aspects of "physical access"; one of those is access while the box is off and no data resident in volatile memory, which is the easy case. Basically there you can just encrypt the non- volatile storage. If the system is *on* and has unencrypted data in memory (such as suspend-to-RAM for example) then you *HAVE* to ensure that it can't be easily disassembled and a hardware debugger attached; there is no way around that very fundamental limitation. Basically if the key is resident and unencrypted as is necessary to *USE* the system, then no amount of hardware is going to *prevent* a dedicated attacker from getting at it unless you make it so unportable that you don't have to worry about somebody carrying it off in the first place. Typical mechanisms to increase the time and effort to break into a device include wiring the entire enclosure with extremely thin filament wires and detecting automatically wiping the system upon any variation in a small flow of current through said filament. this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the "CDROM" entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. Under this setup, tinkering with my BIOS does virtually nothing; the only avenues of attack are strictly of the "Install a hardware keylogger" variety. Doesn't flashing/replacing your BIOS firmware/chip count as tinkering? Then I don't really need a "hardware keylogger", do I ... Ok, so you are saying your plan of attack on this system would be: 1) Steal the laptop such that I don't notice it has been stolen 2) Open it up 3) Replace the very-vendor-specific BIOS chip with a reflashed one with sufficient storage to do all the things the old BIOS could *AND* have enough storage for an entire replacement kernel binary with a built-in keylogger, as well as some storage for the logged password 4) Return the laptop, again such that I don't notice it has been missing 5) Wait for me to boot and type my password 6) Somehow recover the laptop *yet* *again* to get the password back off of it and decrypt the disk Yes it "can be done", but so can dumping the firmware for an iPod out through the built-in piezo clicker[1]. USE SOME COMMON SENSE HERE PEOPLE!!! The only "unbreakable" computer is one always disconnected and off under armed guard in a bank vault, and even then it's only as secure as the bank in which it is stored (which get broken into on occasion). I am assuming that if the laptop has sufficiently important data on it to warrant the above steps then I am also clueful enough to: (A) Not carry the laptop around unsecured areas, (B) Keep a close enough eye on it and be aware that it's gone by the time they get to step 2, OR (C) Pay somebody to build me a better physical chassis for my laptop We are talking about *STANDARD* laptop systems with reasonably alert users. If the user doesn't know how to properly protect the stuff on the laptop then they probably don't know how to properly protect the other copy in their heads, either. Besides, if some government wanted the data on your laptop that bad they'd just pick you up in the
Re: NFS4 authentification / fsuid
On Fri, 7 Sep 2007, Kyle Moffett wrote: > > So you can't draw any relationships between "Protect the end-user" with > "Protect the device FROM the end-user", the former can be done very reliably ^^^ *attacker* > to whatever level of risk-reduction you need and the latter can't practically > be done at all. Well, you're the one who called solving the physical access problem "easy" here ... :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 6 Sep 2007, Kyle Moffett wrote: > > On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: > > > > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: > > > > > > On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: > > > > The question of how to protect against someone with *physical* ^^^ > > > > access certainly is more difficult, but surely that's a separate ^^ > > > > problem. > > > > > > Actually, that's a fairly simple problem (barring disassembling the system > > > and attaching a hardware debugger). You encrypt the root filesystem and > > > require a password to boot (See: LUKS). Debian has built-in support for > > > installing onto fs-on-LVM-on-crypt-on-RAID, and it works quite well on all > > > the laptops I use regularly. It's not even much of a speed penalty; once > > > you take the overhead of hitting a 5400RPM laptop drive you can chew > > > thousands of cycles of CPU without anybody noticing (much). Then all you > > > have to do is burn a copy of your /boot with bootloader onto some > > > read-only media (like a finalized CDROM/DVDROM) and you're set to go. > > > > Disconnect battery, and watch boot password go 'poof!'. > > Umm, I did say "encrypt the root filesystem", didn't I? Booting my laptops ^^^ The whole *point* here is to secure against physical access -- then how can you assume "barring disassembling the system"? If you're not considering attacks such as those, then how _are_ you solving the physical access problem in the first place? :-) > this way follows this procedure: > 1) Enter BIOS boot menu > 2) Insert /boot CDROM > 3) Select the "CDROM" entry > 4) Wait for kernel to start and run through initramfs > 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT > FILESYSTEM > 6) Continue to boot the system. > > Under this setup, tinkering with my BIOS does virtually nothing; the only > avenues of attack are strictly of the "Install a hardware keylogger" variety. Doesn't flashing/replacing your BIOS firmware/chip count as tinkering? Then I don't really need a "hardware keylogger", do I ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Fri, 7 Sep 2007, J. Bruce Fields wrote: > > On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote: > > Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs, > > but you get the gist > > > > The point is that it is easy to subvert userspace if you have enough > > privileges. In the above example it may not be entirely undetectable, > > but who here is running a script on every login to check that / is > > indeed uncompromised? > > I suppose this is the motivation for things like the "secure attention > key"? > > But I'm most curious actually about to what degree the kernel itself is > vulnerable to root (without a reboot). Is disabling /dev/kmem and > module-loading in theory enough? No, not in theory, not in practice. But yeah, restricting an attacker's ability to hack hardware (by controlling physical access) does take out a whole class of attack vectors. But, seriously, such discussion has the tendency to quickly get t theoretical (thus losing practical significance). For example, would we not also need to prevent the (userspace) superuser from being able to run arbitrary executables that can modify firmware? Okay, let's say we have a kernelspace infrastructure of verifying cryptographic signatures on binaries before executing them ... but how practical/usable is this? How practically/universally applicable is a system whose security derives from keeping machines behind locked doors and protected by incorruptible, armed guard? Overall, I tend to be unenthusiastic about most schemes that claim to have solved the user-kernel security problem (with no loss of usability/ practicality). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 6 Sep 2007, J. Bruce Fields wrote: > > On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: > > Oh and btw, note that we're talking of the (lack of) security of a > > "running kernel" here -- because across reboots, there is /really/ > > *absolutely* no such thing as "kernelspace security" because the superuser > > will simply switch the vmlinuz itself ... > > Well, the machine could be booting from cdrom, and could live in a > locked machine room. And how is this different from the "trusted tamperproof hardware" solution I proposed earlier? From an attack vector p.o.v. they are both precisely the same -- both of them are designed to prevent the attacker from gaining unfettered access to system hardware, hmm? Oh, actually, if past history is anything to go by, then your scheme is provably weaker. Security systems are invariably always broken at their weakest link, which is invariably always the human/social element, and your scheme derives its security by relying on *social* element. To elaborate my point, what prevents me from bribing / torturing / blackmailing whoever owns the key to that locked server room and ... The attack is "non-technical", but hey, so was your security :-) > Or people with root on a virtual host don't > necessarily have the ability to replace the kernel for that host. Again, you're restricting physical access ... but okay, this is a slightly more plausible solution (but one that applies to only a *specific* kind of situation). Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Fri, 7 Sep 2007, J. Bruce Fields wrote: On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote: Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs, but you get the gist The point is that it is easy to subvert userspace if you have enough privileges. In the above example it may not be entirely undetectable, but who here is running a script on every login to check that / is indeed uncompromised? I suppose this is the motivation for things like the secure attention key? But I'm most curious actually about to what degree the kernel itself is vulnerable to root (without a reboot). Is disabling /dev/kmem and module-loading in theory enough? No, not in theory, not in practice. But yeah, restricting an attacker's ability to hack hardware (by controlling physical access) does take out a whole class of attack vectors. But, seriously, such discussion has the tendency to quickly get t theoretical (thus losing practical significance). For example, would we not also need to prevent the (userspace) superuser from being able to run arbitrary executables that can modify firmware? Okay, let's say we have a kernelspace infrastructure of verifying cryptographic signatures on binaries before executing them ... but how practical/usable is this? How practically/universally applicable is a system whose security derives from keeping machines behind locked doors and protected by incorruptible, armed guard? Overall, I tend to be unenthusiastic about most schemes that claim to have solved the user-kernel security problem (with no loss of usability/ practicality). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 6 Sep 2007, J. Bruce Fields wrote: On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: Oh and btw, note that we're talking of the (lack of) security of a running kernel here -- because across reboots, there is /really/ *absolutely* no such thing as kernelspace security because the superuser will simply switch the vmlinuz itself ... Well, the machine could be booting from cdrom, and could live in a locked machine room. And how is this different from the trusted tamperproof hardware solution I proposed earlier? From an attack vector p.o.v. they are both precisely the same -- both of them are designed to prevent the attacker from gaining unfettered access to system hardware, hmm? Oh, actually, if past history is anything to go by, then your scheme is provably weaker. Security systems are invariably always broken at their weakest link, which is invariably always the human/social element, and your scheme derives its security by relying on *social* element. To elaborate my point, what prevents me from bribing / torturing / blackmailing whoever owns the key to that locked server room and ... The attack is non-technical, but hey, so was your security :-) Or people with root on a virtual host don't necessarily have the ability to replace the kernel for that host. Again, you're restricting physical access ... but okay, this is a slightly more plausible solution (but one that applies to only a *specific* kind of situation). Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 6 Sep 2007, Kyle Moffett wrote: On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: The question of how to protect against someone with *physical* ^^^ access certainly is more difficult, but surely that's a separate ^^ problem. Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Umm, I did say encrypt the root filesystem, didn't I? Booting my laptops ^^^ The whole *point* here is to secure against physical access -- then how can you assume barring disassembling the system? If you're not considering attacks such as those, then how _are_ you solving the physical access problem in the first place? :-) this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the CDROM entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. Under this setup, tinkering with my BIOS does virtually nothing; the only avenues of attack are strictly of the Install a hardware keylogger variety. Doesn't flashing/replacing your BIOS firmware/chip count as tinkering? Then I don't really need a hardware keylogger, do I ... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Fri, 7 Sep 2007, Kyle Moffett wrote: So you can't draw any relationships between Protect the end-user with Protect the device FROM the end-user, the former can be done very reliably ^^^ *attacker* to whatever level of risk-reduction you need and the latter can't practically be done at all. Well, you're the one who called solving the physical access problem easy here ... :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote: On Thu, 6 Sep 2007, Kyle Moffett wrote: On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: The question of how to protect against someone with *physical* access certainly is more difficult, but surely that's a separate problem. Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on- crypt-on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/ DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Umm, I did say encrypt the root filesystem, didn't I? Booting my laptops The whole *point* here is to secure against physical access -- then how can you assume barring disassembling the system? If you're not considering attacks such as those, then how _are_ you solving the physical access problem in the first place? :-) Security is about fractional reduction of risk, and anybody who tells you otherwise is either ignorant or lying through their teeth. There are *multiple* aspects of physical access; one of those is access while the box is off and no data resident in volatile memory, which is the easy case. Basically there you can just encrypt the non- volatile storage. If the system is *on* and has unencrypted data in memory (such as suspend-to-RAM for example) then you *HAVE* to ensure that it can't be easily disassembled and a hardware debugger attached; there is no way around that very fundamental limitation. Basically if the key is resident and unencrypted as is necessary to *USE* the system, then no amount of hardware is going to *prevent* a dedicated attacker from getting at it unless you make it so unportable that you don't have to worry about somebody carrying it off in the first place. Typical mechanisms to increase the time and effort to break into a device include wiring the entire enclosure with extremely thin filament wires and detecting automatically wiping the system upon any variation in a small flow of current through said filament. this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the CDROM entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. Under this setup, tinkering with my BIOS does virtually nothing; the only avenues of attack are strictly of the Install a hardware keylogger variety. Doesn't flashing/replacing your BIOS firmware/chip count as tinkering? Then I don't really need a hardware keylogger, do I ... Ok, so you are saying your plan of attack on this system would be: 1) Steal the laptop such that I don't notice it has been stolen 2) Open it up 3) Replace the very-vendor-specific BIOS chip with a reflashed one with sufficient storage to do all the things the old BIOS could *AND* have enough storage for an entire replacement kernel binary with a built-in keylogger, as well as some storage for the logged password 4) Return the laptop, again such that I don't notice it has been missing 5) Wait for me to boot and type my password 6) Somehow recover the laptop *yet* *again* to get the password back off of it and decrypt the disk Yes it can be done, but so can dumping the firmware for an iPod out through the built-in piezo clicker[1]. USE SOME COMMON SENSE HERE PEOPLE!!! The only unbreakable computer is one always disconnected and off under armed guard in a bank vault, and even then it's only as secure as the bank in which it is stored (which get broken into on occasion). I am assuming that if the laptop has sufficiently important data on it to warrant the above steps then I am also clueful enough to: (A) Not carry the laptop around unsecured areas, (B) Keep a close enough eye on it and be aware that it's gone by the time they get to step 2, OR (C) Pay somebody to build me a better physical chassis for my laptop We are talking about *STANDARD* laptop systems with reasonably alert users. If the user doesn't know how to properly protect the stuff on the laptop then they probably don't know how to properly protect the other copy in their heads, either. Besides, if some government wanted the data on your laptop that bad they'd just pick you up in the middle of the night
Re: NFS4 authentification / fsuid
On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote: > Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs, > but you get the gist > > The point is that it is easy to subvert userspace if you have enough > privileges. In the above example it may not be entirely undetectable, > but who here is running a script on every login to check that / is > indeed uncompromised? I suppose this is the motivation for things like the "secure attention key"? But I'm most curious actually about to what degree the kernel itself is vulnerable to root (without a reboot). Is disabling /dev/kmem and module-loading in theory enough? (Modulo bugs like filesystems that aren't secure against untrusted filesystems, etc.) --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
In article <[EMAIL PROTECTED]> you wrote: > So you can't draw any relationships between "Protect the end-user" > with "Protect the device FROM the end-user", the former can be done > very reliably to whatever level of risk-reduction you need and the > latter can't practically be done at all. Unless you use a TPM Chip. Gruss Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote: Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs, but you get the gist The point is that it is easy to subvert userspace if you have enough privileges. In the above example it may not be entirely undetectable, but who here is running a script on every login to check that / is indeed uncompromised? I suppose this is the motivation for things like the secure attention key? But I'm most curious actually about to what degree the kernel itself is vulnerable to root (without a reboot). Is disabling /dev/kmem and module-loading in theory enough? (Modulo bugs like filesystems that aren't secure against untrusted filesystems, etc.) --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
In article [EMAIL PROTECTED] you wrote: So you can't draw any relationships between Protect the end-user with Protect the device FROM the end-user, the former can be done very reliably to whatever level of risk-reduction you need and the latter can't practically be done at all. Unless you use a TPM Chip. Gruss Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 07, 2007, at 01:14:09, Trond Myklebust wrote: On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote: Umm, I did say "encrypt the root filesystem", didn't I? Booting my laptops this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the "CDROM" entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. [...] the only avenues of attack are strictly of the "Install a hardware keylogger" variety. So an attacker will instead install a hardware keylogger, or swap out your boot cdrom with a compromised but almost identical boot cdrom instead, or mod your bios, ... A fully self-certifying system that can prevent any attack is _very_ hard to achieve. Just ask apple (iPhone) or any games console vendor... A fully self-certifying system that can prevent any attack is impossible to achieve. If I have the device and can devote as many hours as I want to breaking into it, there is exactly ZERO way to prevent that, aside from encrypting things and not giving out the key (which sorta makes it useless but is precisely the point of real crypto). There is a HUGE difference between "I don't want the end-user to hack into this" and "The end-user wants a certain degree of assurance that his data can't be compromised. In the former case (IE: DRM) you are NOT using cryptography because you are giving the user: (A) the data, (B) the algorithm, and (C) the key, which means they can decrypt it ANY TIME THEY WANT. In the latter case the attacker DOES NOT have the key and virtually all of the attacks forms of "How do I get the key?". The end-user is REQUIRED to provide an appropriate level of physical security based on the nature of the data; If I'm that worried about somebody substituting my /boot CD, then I'm going to make DAMN sure that I keep it on my person at all times. So you can't draw any relationships between "Protect the end-user" with "Protect the device FROM the end-user", the former can be done very reliably to whatever level of risk-reduction you need and the latter can't practically be done at all. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote: > On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: > > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: > >> Actually, that's a fairly simple problem (barring disassembling > >> the system and attaching a hardware debugger). You encrypt the > >> root filesystem and require a password to boot (See: LUKS). > >> Debian has built-in support for installing onto fs-on-LVM-on-crypt- > >> on-RAID, and it works quite well on all the laptops I use > >> regularly. It's not even much of a speed penalty; once you take > >> the overhead of hitting a 5400RPM laptop drive you can chew > >> thousands of cycles of CPU without anybody noticing (much). Then > >> all you have to do is burn a copy of your /boot with bootloader > >> onto some read-only media (like a finalized CDROM/DVDROM) and > >> you're set to go. > > > > Disconnect battery, and watch boot password go 'poof!'. > > Umm, I did say "encrypt the root filesystem", didn't I? Booting my > laptops this way follows this procedure: >1) Enter BIOS boot menu >2) Insert /boot CDROM >3) Select the "CDROM" entry >4) Wait for kernel to start and run through initramfs >5) Type password into the initramfs prompt so that it can DECRYPT > THE ROOT FILESYSTEM >6) Continue to boot the system. > > Under this setup, tinkering with my BIOS does virtually nothing; the > only avenues of attack are strictly of the "Install a hardware > keylogger" variety. Without my "boot" password you are looking at a > block device which appears to be little more than a random bit- > bucket, using AES-256 encryption. If you can break that by > disconnecting the BIOS battery a lot of governments would be very > interested in the exact procedure. :-D Furthermore if I think that > the hardware has been compromised I can pull out the HDD and my CDROM > and take them to a trusted computer to gain access to my data. > > That said, a useful BIOS password helps keep somebody from casually > setting a supervisor password or mucking with the critical-to-boot > settings and making _me_ unplug the battery. > > Cheers, > Kyle Moffett So an attacker will instead install a hardware keylogger, or swap out your boot cdrom with a compromised but almost identical boot cdrom instead, or mod your bios, ... A fully self-certifying system that can prevent any attack is _very_ hard to achieve. Just ask apple (iPhone) or any games console vendor... Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on-crypt- on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Umm, I did say "encrypt the root filesystem", didn't I? Booting my laptops this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the "CDROM" entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. Under this setup, tinkering with my BIOS does virtually nothing; the only avenues of attack are strictly of the "Install a hardware keylogger" variety. Without my "boot" password you are looking at a block device which appears to be little more than a random bit- bucket, using AES-256 encryption. If you can break that by disconnecting the BIOS battery a lot of governments would be very interested in the exact procedure. :-D Furthermore if I think that the hardware has been compromised I can pull out the HDD and my CDROM and take them to a trusted computer to gain access to my data. That said, a useful BIOS password helps keep somebody from casually setting a supervisor password or mucking with the critical-to-boot settings and making _me_ unplug the battery. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote: Like Trond said, there are very high number of ways in which privileged userspace can compromise a running kernel if it really wants to do that, root-is-God has always been *the* major problem with Unix :-) The only _real_ way a kernel can lock itself completely against malicious userspace involves trusted tamperproof hardware, The question of how to protect against someone with *physical* access certainly is more difficult, but surely that's a separate problem. Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/DVDROM) and you're set to go. Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: > On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: > > On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote: > >> Like Trond said, there are very high number of ways in which > >> privileged userspace can compromise a running kernel if it really > >> wants to do that, root-is-God has always been *the* major problem > >> with Unix :-) > >> > >> The only _real_ way a kernel can lock itself completely against > >> malicious userspace involves trusted tamperproof hardware, > > > > The question of how to protect against someone with *physical* > > access certainly is more difficult, but surely that's a separate > > problem. > > Actually, that's a fairly simple problem (barring disassembling the > system and attaching a hardware debugger). You encrypt the root > filesystem and require a password to boot (See: LUKS). Debian has > built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and > it works quite well on all the laptops I use regularly. It's not > even much of a speed penalty; once you take the overhead of hitting a > 5400RPM laptop drive you can chew thousands of cycles of CPU without > anybody noticing (much). Then all you have to do is burn a copy of > your /boot with bootloader onto some read-only media (like a > finalized CDROM/DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Fri, 2007-09-07 at 01:21 +0200, Trond Myklebust wrote: > On Thu, 2007-09-06 at 11:11 -0400, J. Bruce Fields wrote: > > On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: > > > Oh and btw, note that we're talking of the (lack of) security of a > > > "running kernel" here -- because across reboots, there is /really/ > > > *absolutely* no such thing as "kernelspace security" because the superuser > > > will simply switch the vmlinuz itself ... > > > > Well, the machine could be booting from cdrom, and could live in a > > locked machine room. Or people with root on a virtual host don't > > necessarily have the ability to replace the kernel for that host. > > mount -t tmpfs none /my_tmpfs > cd /my_tmpfs > cp -a /bin bin > cp -p my_keylogging_pam_module.so lib > pivot_root . /old-root Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs, but you get the gist The point is that it is easy to subvert userspace if you have enough privileges. In the above example it may not be entirely undetectable, but who here is running a script on every login to check that / is indeed uncompromised? Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-09-06 at 11:11 -0400, J. Bruce Fields wrote: > On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: > > Oh and btw, note that we're talking of the (lack of) security of a > > "running kernel" here -- because across reboots, there is /really/ > > *absolutely* no such thing as "kernelspace security" because the superuser > > will simply switch the vmlinuz itself ... > > Well, the machine could be booting from cdrom, and could live in a > locked machine room. Or people with root on a virtual host don't > necessarily have the ability to replace the kernel for that host. mount -t tmpfs none /my_tmpfs cd /my_tmpfs cp -a /bin bin cp -p my_keylogging_pam_module.so lib pivot_root . /old-root to take another example - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: > Oh and btw, note that we're talking of the (lack of) security of a > "running kernel" here -- because across reboots, there is /really/ > *absolutely* no such thing as "kernelspace security" because the superuser > will simply switch the vmlinuz itself ... Well, the machine could be booting from cdrom, and could live in a locked machine room. Or people with root on a virtual host don't necessarily have the ability to replace the kernel for that host. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote: > /dev/kmem was just an example -- IMHO differentiating between kernel and > userspace from a security p.o.v. is always tricky. The things that come to mind are /dev/kmem and module-loading. What else is there? And what is it that makes this inherently difficult? > Like Trond said, there are very high number of ways in which > privileged userspace can compromise a running kernel if it really > wants to do that, root-is-God has always been *the* major problem with > Unix :-) > > The only _real_ way a kernel can lock itself completely against > malicious userspace involves trusted tamperproof hardware, The question of how to protect against someone with *physical* access certainly is more difficult, but surely that's a separate problem. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 6 Sep 2007, Satyam Sharma wrote: > > On Thu, 30 Aug 2007, J. Bruce Fields wrote: > > > On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote: > > > > > What I'm saying is that the superuser can pretty much do whatever it > > > takes to grab either your kerberos password (e.g. install a keyboard > > > listener), a stored credential (read the contents of your kerberos > > > on-disk credential cache), or s/he can access the cached contents of the > > > file by hunting through /dev/kmem. > > > > > > IOW: There is no such thing as security on a root-compromised machine. > > > > And in theory a kernel could provide *some* guarantees against root, > > right? (Is there some reason a unix-like kernel must provide such > > things as /dev/kmem?) > > /dev/kmem was just an example -- IMHO differentiating between kernel and > userspace from a security p.o.v. is always tricky. Like Trond said, there > are very high number of ways in which privileged userspace can compromise > a running kernel if it really wants to do that, root-is-God has always ^^ Oh and btw, note that we're talking of the (lack of) security of a "running kernel" here -- because across reboots, there is /really/ *absolutely* no such thing as "kernelspace security" because the superuser will simply switch the vmlinuz itself ... > been *the* major problem with Unix :-) > > The only _real_ way a kernel can lock itself completely against malicious > userspace involves trusted tamperproof hardware, but even that only if > you can get yourself to believe such a thing exists in the first place ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 30 Aug 2007, J. Bruce Fields wrote: > On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote: > > With CIFS or other password based protocols (including RPCSEC_GSS) > > Well, rpcsec_gss isn't inherently password based, and you can > authenticate in some way that doesn't actually give away your password > (or other long-lived credential). > > > What I'm saying is that the superuser can pretty much do whatever it > > takes to grab either your kerberos password (e.g. install a keyboard > > listener), a stored credential (read the contents of your kerberos > > on-disk credential cache), or s/he can access the cached contents of the > > file by hunting through /dev/kmem. > > > > IOW: There is no such thing as security on a root-compromised machine. > > And in theory a kernel could provide *some* guarantees against root, > right? (Is there some reason a unix-like kernel must provide such > things as /dev/kmem?) /dev/kmem was just an example -- IMHO differentiating between kernel and userspace from a security p.o.v. is always tricky. Like Trond said, there are very high number of ways in which privileged userspace can compromise a running kernel if it really wants to do that, root-is-God has always been *the* major problem with Unix :-) The only _real_ way a kernel can lock itself completely against malicious userspace involves trusted tamperproof hardware, but even that only if you can get yourself to believe such a thing exists in the first place ;-) Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote: /dev/kmem was just an example -- IMHO differentiating between kernel and userspace from a security p.o.v. is always tricky. The things that come to mind are /dev/kmem and module-loading. What else is there? And what is it that makes this inherently difficult? Like Trond said, there are very high number of ways in which privileged userspace can compromise a running kernel if it really wants to do that, root-is-God has always been *the* major problem with Unix :-) The only _real_ way a kernel can lock itself completely against malicious userspace involves trusted tamperproof hardware, The question of how to protect against someone with *physical* access certainly is more difficult, but surely that's a separate problem. --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: Oh and btw, note that we're talking of the (lack of) security of a running kernel here -- because across reboots, there is /really/ *absolutely* no such thing as kernelspace security because the superuser will simply switch the vmlinuz itself ... Well, the machine could be booting from cdrom, and could live in a locked machine room. Or people with root on a virtual host don't necessarily have the ability to replace the kernel for that host. --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on-crypt- on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Umm, I did say encrypt the root filesystem, didn't I? Booting my laptops this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the CDROM entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. Under this setup, tinkering with my BIOS does virtually nothing; the only avenues of attack are strictly of the Install a hardware keylogger variety. Without my boot password you are looking at a block device which appears to be little more than a random bit- bucket, using AES-256 encryption. If you can break that by disconnecting the BIOS battery a lot of governments would be very interested in the exact procedure. :-D Furthermore if I think that the hardware has been compromised I can pull out the HDD and my CDROM and take them to a trusted computer to gain access to my data. That said, a useful BIOS password helps keep somebody from casually setting a supervisor password or mucking with the critical-to-boot settings and making _me_ unplug the battery. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 07, 2007, at 01:14:09, Trond Myklebust wrote: On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote: Umm, I did say encrypt the root filesystem, didn't I? Booting my laptops this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the CDROM entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. [...] the only avenues of attack are strictly of the Install a hardware keylogger variety. So an attacker will instead install a hardware keylogger, or swap out your boot cdrom with a compromised but almost identical boot cdrom instead, or mod your bios, ... A fully self-certifying system that can prevent any attack is _very_ hard to achieve. Just ask apple (iPhone) or any games console vendor... A fully self-certifying system that can prevent any attack is impossible to achieve. If I have the device and can devote as many hours as I want to breaking into it, there is exactly ZERO way to prevent that, aside from encrypting things and not giving out the key (which sorta makes it useless but is precisely the point of real crypto). There is a HUGE difference between I don't want the end-user to hack into this and The end-user wants a certain degree of assurance that his data can't be compromised. In the former case (IE: DRM) you are NOT using cryptography because you are giving the user: (A) the data, (B) the algorithm, and (C) the key, which means they can decrypt it ANY TIME THEY WANT. In the latter case the attacker DOES NOT have the key and virtually all of the attacks forms of How do I get the key?. The end-user is REQUIRED to provide an appropriate level of physical security based on the nature of the data; If I'm that worried about somebody substituting my /boot CD, then I'm going to make DAMN sure that I keep it on my person at all times. So you can't draw any relationships between Protect the end-user with Protect the device FROM the end-user, the former can be done very reliably to whatever level of risk-reduction you need and the latter can't practically be done at all. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-09-06 at 20:56 -0400, Kyle Moffett wrote: On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote: On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on-crypt- on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Umm, I did say encrypt the root filesystem, didn't I? Booting my laptops this way follows this procedure: 1) Enter BIOS boot menu 2) Insert /boot CDROM 3) Select the CDROM entry 4) Wait for kernel to start and run through initramfs 5) Type password into the initramfs prompt so that it can DECRYPT THE ROOT FILESYSTEM 6) Continue to boot the system. Under this setup, tinkering with my BIOS does virtually nothing; the only avenues of attack are strictly of the Install a hardware keylogger variety. Without my boot password you are looking at a block device which appears to be little more than a random bit- bucket, using AES-256 encryption. If you can break that by disconnecting the BIOS battery a lot of governments would be very interested in the exact procedure. :-D Furthermore if I think that the hardware has been compromised I can pull out the HDD and my CDROM and take them to a trusted computer to gain access to my data. That said, a useful BIOS password helps keep somebody from casually setting a supervisor password or mucking with the critical-to-boot settings and making _me_ unplug the battery. Cheers, Kyle Moffett So an attacker will instead install a hardware keylogger, or swap out your boot cdrom with a compromised but almost identical boot cdrom instead, or mod your bios, ... A fully self-certifying system that can prevent any attack is _very_ hard to achieve. Just ask apple (iPhone) or any games console vendor... Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-09-06 at 11:11 -0400, J. Bruce Fields wrote: On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: Oh and btw, note that we're talking of the (lack of) security of a running kernel here -- because across reboots, there is /really/ *absolutely* no such thing as kernelspace security because the superuser will simply switch the vmlinuz itself ... Well, the machine could be booting from cdrom, and could live in a locked machine room. Or people with root on a virtual host don't necessarily have the ability to replace the kernel for that host. mount -t tmpfs none /my_tmpfs cd /my_tmpfs cp -a /bin bin cp -p my_keylogging_pam_module.so lib pivot_root . /old-root to take another example - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote: On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote: Like Trond said, there are very high number of ways in which privileged userspace can compromise a running kernel if it really wants to do that, root-is-God has always been *the* major problem with Unix :-) The only _real_ way a kernel can lock itself completely against malicious userspace involves trusted tamperproof hardware, The question of how to protect against someone with *physical* access certainly is more difficult, but surely that's a separate problem. Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/DVDROM) and you're set to go. Disconnect battery, and watch boot password go 'poof!'. Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Fri, 2007-09-07 at 01:21 +0200, Trond Myklebust wrote: On Thu, 2007-09-06 at 11:11 -0400, J. Bruce Fields wrote: On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote: Oh and btw, note that we're talking of the (lack of) security of a running kernel here -- because across reboots, there is /really/ *absolutely* no such thing as kernelspace security because the superuser will simply switch the vmlinuz itself ... Well, the machine could be booting from cdrom, and could live in a locked machine room. Or people with root on a virtual host don't necessarily have the ability to replace the kernel for that host. mount -t tmpfs none /my_tmpfs cd /my_tmpfs cp -a /bin bin cp -p my_keylogging_pam_module.so lib pivot_root . /old-root Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs, but you get the gist The point is that it is easy to subvert userspace if you have enough privileges. In the above example it may not be entirely undetectable, but who here is running a script on every login to check that / is indeed uncompromised? Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote: On Thu, Sep 06, 2007 at 01:44:05PM +0530, Satyam Sharma wrote: Like Trond said, there are very high number of ways in which privileged userspace can compromise a running kernel if it really wants to do that, root-is-God has always been *the* major problem with Unix :-) The only _real_ way a kernel can lock itself completely against malicious userspace involves trusted tamperproof hardware, The question of how to protect against someone with *physical* access certainly is more difficult, but surely that's a separate problem. Actually, that's a fairly simple problem (barring disassembling the system and attaching a hardware debugger). You encrypt the root filesystem and require a password to boot (See: LUKS). Debian has built-in support for installing onto fs-on-LVM-on-crypt-on-RAID, and it works quite well on all the laptops I use regularly. It's not even much of a speed penalty; once you take the overhead of hitting a 5400RPM laptop drive you can chew thousands of cycles of CPU without anybody noticing (much). Then all you have to do is burn a copy of your /boot with bootloader onto some read-only media (like a finalized CDROM/DVDROM) and you're set to go. Cheers, Kyle Moffett - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote: > With CIFS or other password based protocols (including RPCSEC_GSS) Well, rpcsec_gss isn't inherently password based, and you can authenticate in some way that doesn't actually give away your password (or other long-lived credential). > What I'm saying is that the superuser can pretty much do whatever it > takes to grab either your kerberos password (e.g. install a keyboard > listener), a stored credential (read the contents of your kerberos > on-disk credential cache), or s/he can access the cached contents of the > file by hunting through /dev/kmem. > > IOW: There is no such thing as security on a root-compromised machine. And in theory a kernel could provide *some* guarantees against root, right? (Is there some reason a unix-like kernel must provide such things as /dev/kmem?) --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Aug 30, 2007 at 04:42:33PM +0200, Jan Engelhardt wrote: > > On Aug 30 2007 10:29, Trond Myklebust wrote: > >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: > >> > >> with NFS3, there is this 'root hole', i.e. any person who has a root > >> account (perhaps by use of a laptop) can mount an export (let's say this > >> export had the "root_squash" option), and still have a look at the user > >> files, because he can locally setuid() into another user. > >> > >> So I was looking for alternatives. CIFS is my favorite candidate, but it > >> has a few issues right now. So does sshfs and about everything I have > >> come across. Since I remember NFS4 can use KRB5 authentification, my > >> question is, will the NFS(4) server process run with an fsuid equal to > >> the user that authenticated? > > > >NFSv3 should work fine with krb5 too, but that won't solve your problem > >with setuid: kerberos saves the TGT in a file on /tmp, so root can still > >suid and grab your cred (and the same goes for CIFS). > > Hm? I do not see this problem with CIFS. The user may have local > root, but on the server, he only has his non-root account on the > server, and as such, can only operate on the server using this > non-root fsuid. Did I miss something? (Especially the /dev/mem thing > is not quite clear to me.) The server will run with an fsuid equal to the user that authenticated, you're correct. So if you require krb5 access on an export, then nfs access to a file on the export should be permitted only on rpc's that are authenticated using credentials of a user with permission to access the file. Trond's pointing out that when you give the client your krb5 credentials you're trusting it to do only what you tell it to with them. You have to trust the client's kernel at the very least, and also root on that client, for the forseeable future. --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-08-30 at 16:42 +0200, Jan Engelhardt wrote: > On Aug 30 2007 10:29, Trond Myklebust wrote: > >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: > >> > >> with NFS3, there is this 'root hole', i.e. any person who has a root > >> account (perhaps by use of a laptop) can mount an export (let's say this > >> export had the "root_squash" option), and still have a look at the user > >> files, because he can locally setuid() into another user. > >> > >> So I was looking for alternatives. CIFS is my favorite candidate, but it > >> has a few issues right now. So does sshfs and about everything I have > >> come across. Since I remember NFS4 can use KRB5 authentification, my > >> question is, will the NFS(4) server process run with an fsuid equal to > >> the user that authenticated? > > > >NFSv3 should work fine with krb5 too, but that won't solve your problem > >with setuid: kerberos saves the TGT in a file on /tmp, so root can still > >suid and grab your cred (and the same goes for CIFS). > > Hm? I do not see this problem with CIFS. The user may have local > root, but on the server, he only has his non-root account on the > server, and as such, can only operate on the server using this > non-root fsuid. With CIFS or other password based protocols (including RPCSEC_GSS) all the root user needs in order to steal your identity is to grab a copy of your password or a credential. It is not quite as trivial to do as changing uid, but it is hardly rocket science if the compromised machine is one that you log into regularly. > Did I miss something? (Especially the /dev/mem thing > is not quite clear to me.) > > >BTW: even when this task is done, a creative root can still find ways to > >subvert the security (he can read /dev/mem, replace the kernel with a > >compromised one, ). The bottom line is that if you can't trust root, > >don't even log in. What I'm saying is that the superuser can pretty much do whatever it takes to grab either your kerberos password (e.g. install a keyboard listener), a stored credential (read the contents of your kerberos on-disk credential cache), or s/he can access the cached contents of the file by hunting through /dev/kmem. IOW: There is no such thing as security on a root-compromised machine. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Aug 30 2007 10:29, Trond Myklebust wrote: >On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: >> >> with NFS3, there is this 'root hole', i.e. any person who has a root >> account (perhaps by use of a laptop) can mount an export (let's say this >> export had the "root_squash" option), and still have a look at the user >> files, because he can locally setuid() into another user. >> >> So I was looking for alternatives. CIFS is my favorite candidate, but it >> has a few issues right now. So does sshfs and about everything I have >> come across. Since I remember NFS4 can use KRB5 authentification, my >> question is, will the NFS(4) server process run with an fsuid equal to >> the user that authenticated? > >NFSv3 should work fine with krb5 too, but that won't solve your problem >with setuid: kerberos saves the TGT in a file on /tmp, so root can still >suid and grab your cred (and the same goes for CIFS). Hm? I do not see this problem with CIFS. The user may have local root, but on the server, he only has his non-root account on the server, and as such, can only operate on the server using this non-root fsuid. Did I miss something? (Especially the /dev/mem thing is not quite clear to me.) >BTW: even when this task is done, a creative root can still find ways to >subvert the security (he can read /dev/mem, replace the kernel with a >compromised one, ). The bottom line is that if you can't trust root, >don't even log in. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-08-30 at 10:29 -0400, Trond Myklebust wrote: > We've got people working on fixing this problem using David Howells' > keyrings, but it will probably be a while until we've solved all the > upcall issues, and it will probably take even longer to push the > kerberos changes back to the official MIT etc distros. BTW: even when this task is done, a creative root can still find ways to subvert the security (he can read /dev/mem, replace the kernel with a compromised one, ). The bottom line is that if you can't trust root, don't even log in. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: > Hi, > > > with NFS3, there is this 'root hole', i.e. any person who has a root > account (perhaps by use of a laptop) can mount an export (let's say this > export had the "root_squash" option), and still have a look at the user > files, because he can locally setuid() into another user. > > So I was looking for alternatives. CIFS is my favorite candidate, but it > has a few issues right now. So does sshfs and about everything I have > come across. Since I remember NFS4 can use KRB5 authentification, my > question is, will the NFS(4) server process run with an fsuid equal to > the user that authenticated? > > > thanks, > Jan NFSv3 should work fine with krb5 too, but that won't solve your problem with setuid: kerberos saves the TGT in a file on /tmp, so root can still suid and grab your cred (and the same goes for CIFS). We've got people working on fixing this problem using David Howells' keyrings, but it will probably be a while until we've solved all the upcall issues, and it will probably take even longer to push the kerberos changes back to the official MIT etc distros. Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS4 authentification / fsuid
Hi, with NFS3, there is this 'root hole', i.e. any person who has a root account (perhaps by use of a laptop) can mount an export (let's say this export had the "root_squash" option), and still have a look at the user files, because he can locally setuid() into another user. So I was looking for alternatives. CIFS is my favorite candidate, but it has a few issues right now. So does sshfs and about everything I have come across. Since I remember NFS4 can use KRB5 authentification, my question is, will the NFS(4) server process run with an fsuid equal to the user that authenticated? thanks, Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS4 authentification / fsuid
Hi, with NFS3, there is this 'root hole', i.e. any person who has a root account (perhaps by use of a laptop) can mount an export (let's say this export had the root_squash option), and still have a look at the user files, because he can locally setuid() into another user. So I was looking for alternatives. CIFS is my favorite candidate, but it has a few issues right now. So does sshfs and about everything I have come across. Since I remember NFS4 can use KRB5 authentification, my question is, will the NFS(4) server process run with an fsuid equal to the user that authenticated? thanks, Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: Hi, with NFS3, there is this 'root hole', i.e. any person who has a root account (perhaps by use of a laptop) can mount an export (let's say this export had the root_squash option), and still have a look at the user files, because he can locally setuid() into another user. So I was looking for alternatives. CIFS is my favorite candidate, but it has a few issues right now. So does sshfs and about everything I have come across. Since I remember NFS4 can use KRB5 authentification, my question is, will the NFS(4) server process run with an fsuid equal to the user that authenticated? thanks, Jan NFSv3 should work fine with krb5 too, but that won't solve your problem with setuid: kerberos saves the TGT in a file on /tmp, so root can still suid and grab your cred (and the same goes for CIFS). We've got people working on fixing this problem using David Howells' keyrings, but it will probably be a while until we've solved all the upcall issues, and it will probably take even longer to push the kerberos changes back to the official MIT etc distros. Cheers Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-08-30 at 10:29 -0400, Trond Myklebust wrote: We've got people working on fixing this problem using David Howells' keyrings, but it will probably be a while until we've solved all the upcall issues, and it will probably take even longer to push the kerberos changes back to the official MIT etc distros. BTW: even when this task is done, a creative root can still find ways to subvert the security (he can read /dev/mem, replace the kernel with a compromised one, ). The bottom line is that if you can't trust root, don't even log in. Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Aug 30 2007 10:29, Trond Myklebust wrote: On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: with NFS3, there is this 'root hole', i.e. any person who has a root account (perhaps by use of a laptop) can mount an export (let's say this export had the root_squash option), and still have a look at the user files, because he can locally setuid() into another user. So I was looking for alternatives. CIFS is my favorite candidate, but it has a few issues right now. So does sshfs and about everything I have come across. Since I remember NFS4 can use KRB5 authentification, my question is, will the NFS(4) server process run with an fsuid equal to the user that authenticated? NFSv3 should work fine with krb5 too, but that won't solve your problem with setuid: kerberos saves the TGT in a file on /tmp, so root can still suid and grab your cred (and the same goes for CIFS). Hm? I do not see this problem with CIFS. The user may have local root, but on the server, he only has his non-root account on the server, and as such, can only operate on the server using this non-root fsuid. Did I miss something? (Especially the /dev/mem thing is not quite clear to me.) BTW: even when this task is done, a creative root can still find ways to subvert the security (he can read /dev/mem, replace the kernel with a compromised one, ). The bottom line is that if you can't trust root, don't even log in. Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, 2007-08-30 at 16:42 +0200, Jan Engelhardt wrote: On Aug 30 2007 10:29, Trond Myklebust wrote: On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: with NFS3, there is this 'root hole', i.e. any person who has a root account (perhaps by use of a laptop) can mount an export (let's say this export had the root_squash option), and still have a look at the user files, because he can locally setuid() into another user. So I was looking for alternatives. CIFS is my favorite candidate, but it has a few issues right now. So does sshfs and about everything I have come across. Since I remember NFS4 can use KRB5 authentification, my question is, will the NFS(4) server process run with an fsuid equal to the user that authenticated? NFSv3 should work fine with krb5 too, but that won't solve your problem with setuid: kerberos saves the TGT in a file on /tmp, so root can still suid and grab your cred (and the same goes for CIFS). Hm? I do not see this problem with CIFS. The user may have local root, but on the server, he only has his non-root account on the server, and as such, can only operate on the server using this non-root fsuid. With CIFS or other password based protocols (including RPCSEC_GSS) all the root user needs in order to steal your identity is to grab a copy of your password or a credential. It is not quite as trivial to do as changing uid, but it is hardly rocket science if the compromised machine is one that you log into regularly. Did I miss something? (Especially the /dev/mem thing is not quite clear to me.) BTW: even when this task is done, a creative root can still find ways to subvert the security (he can read /dev/mem, replace the kernel with a compromised one, ). The bottom line is that if you can't trust root, don't even log in. What I'm saying is that the superuser can pretty much do whatever it takes to grab either your kerberos password (e.g. install a keyboard listener), a stored credential (read the contents of your kerberos on-disk credential cache), or s/he can access the cached contents of the file by hunting through /dev/kmem. IOW: There is no such thing as security on a root-compromised machine. Trond - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Aug 30, 2007 at 04:42:33PM +0200, Jan Engelhardt wrote: On Aug 30 2007 10:29, Trond Myklebust wrote: On Thu, 2007-08-30 at 16:12 +0200, Jan Engelhardt wrote: with NFS3, there is this 'root hole', i.e. any person who has a root account (perhaps by use of a laptop) can mount an export (let's say this export had the root_squash option), and still have a look at the user files, because he can locally setuid() into another user. So I was looking for alternatives. CIFS is my favorite candidate, but it has a few issues right now. So does sshfs and about everything I have come across. Since I remember NFS4 can use KRB5 authentification, my question is, will the NFS(4) server process run with an fsuid equal to the user that authenticated? NFSv3 should work fine with krb5 too, but that won't solve your problem with setuid: kerberos saves the TGT in a file on /tmp, so root can still suid and grab your cred (and the same goes for CIFS). Hm? I do not see this problem with CIFS. The user may have local root, but on the server, he only has his non-root account on the server, and as such, can only operate on the server using this non-root fsuid. Did I miss something? (Especially the /dev/mem thing is not quite clear to me.) The server will run with an fsuid equal to the user that authenticated, you're correct. So if you require krb5 access on an export, then nfs access to a file on the export should be permitted only on rpc's that are authenticated using credentials of a user with permission to access the file. Trond's pointing out that when you give the client your krb5 credentials you're trusting it to do only what you tell it to with them. You have to trust the client's kernel at the very least, and also root on that client, for the forseeable future. --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS4 authentification / fsuid
On Thu, Aug 30, 2007 at 11:04:00AM -0400, Trond Myklebust wrote: With CIFS or other password based protocols (including RPCSEC_GSS) Well, rpcsec_gss isn't inherently password based, and you can authenticate in some way that doesn't actually give away your password (or other long-lived credential). What I'm saying is that the superuser can pretty much do whatever it takes to grab either your kerberos password (e.g. install a keyboard listener), a stored credential (read the contents of your kerberos on-disk credential cache), or s/he can access the cached contents of the file by hunting through /dev/kmem. IOW: There is no such thing as security on a root-compromised machine. And in theory a kernel could provide *some* guarantees against root, right? (Is there some reason a unix-like kernel must provide such things as /dev/kmem?) --b. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
