Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <he...@zu...> - 2004-02-08 16:07:47
|
Hey folks, I need to implement the option of remotely updating DL when it's on a USB stick or something. So far I couldn't really decide how I want to do this, so it's reliable and most of all secure. The update must be signed (pgp) and performed from within initrd, that's the easy part. My original idea was to add the iso image as boot.cd.new to the root of the media and then just check for it's existence, verify it, rename it to bootcd.iso and continue. The major problem is that it's easy to temper with the verification of the signature, by replacing the initrd on the memory stick. any ideas? suggestions ? cu Heiko |
|
From: Bruce S. <bw...@ar...> - 2004-02-08 16:51:01
|
> I need to implement the option of remotely updating DL when it's on a > USB stick or something. > > So far I couldn't really decide how I want to do this, so it's reliable > and most of all secure. > > The update must be signed (pgp) and performed from within initrd, that's > the easy part. > > My original idea was to add the iso image as boot.cd.new to the root of > the media and then just check for it's existence, verify it, rename it > to bootcd.iso and continue. So, the USB stick has to be large enough to hold TWO copies of the ISO? > The major problem is that it's easy to temper with the verification of > the signature, by replacing the initrd on the memory stick. You could put the sig on a secure location on the internet instead of on the media. But then initrd would need the network up. :-( - BS |
|
From: Friedrich L. <fl...@fl...> - 2004-02-08 17:17:20
|
Bruce Smith wrote on 08.02.2004 17:50 MET: >>The update must be signed (pgp) and performed from within initrd, that's >>the easy part. >> >>My original idea was to add the iso image as boot.cd.new to the root of >>the media and then just check for it's existence, verify it, rename it >>to bootcd.iso and continue. > > > So, the USB stick has to be large enough to hold TWO copies of the ISO? Hmmm...yes we can not overwrite the current ISO as it is currently mounted. What if we go back to load everything into memory? Then we could just replace the ISO on the memory stick (incl. its signature file) in place. What is cheaper? RAM or USB-Memory sticks? BTW how do we handle the ISOs created with custom-cd? -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2004-02-08 19:51:25
|
Friedrich Lobenstock wrote: > Bruce Smith wrote on 08.02.2004 17:50 MET: > >>> The update must be signed (pgp) and performed from within initrd, >>> that's the easy part. >>> >>> My original idea was to add the iso image as boot.cd.new to the root >>> of the media and then just check for it's existence, verify it, >>> rename it to bootcd.iso and continue. >> >> >> >> So, the USB stick has to be large enough to hold TWO copies of the ISO? > > > Hmmm...yes we can not overwrite the current ISO as it is currently > mounted. What if we go back to load everything into memory? Then > we could just replace the ISO on the memory stick (incl. its > signature file) in place. What is cheaper? RAM or USB-Memory sticks? That would require hundreds of MBs. I would say if somebody wants to use this feature, he has to provide the necessary space on this stick or whereever it is on. > BTW how do we handle the ISOs created with custom-cd? Since the User will replace the ISO himself, he can do it with whatever version he prefers. Heiko |
|
From: Friedrich L. <fl...@fl...> - 2004-02-08 20:15:09
|
Heiko Zuerker wrote on 08.02.2004 20:46 MET: > Friedrich Lobenstock wrote: > >> Bruce Smith wrote on 08.02.2004 17:50 MET: >> >>>> The update must be signed (pgp) and performed from within initrd, >>>> that's the easy part. >>>> >>>> My original idea was to add the iso image as boot.cd.new to the root >>>> of the media and then just check for it's existence, verify it, >>>> rename it to bootcd.iso and continue. >>> >>> >>> >>> >>> So, the USB stick has to be large enough to hold TWO copies of the ISO? >> >> >> >> Hmmm...yes we can not overwrite the current ISO as it is currently >> mounted. What if we go back to load everything into memory? Then >> we could just replace the ISO on the memory stick (incl. its >> signature file) in place. What is cheaper? RAM or USB-Memory sticks? > > > That would require hundreds of MBs. I would say if somebody wants to use > this feature, he has to provide the necessary space on this stick or > whereever it is on. > >> BTW how do we handle the ISOs created with custom-cd? > > > Since the User will replace the ISO himself, he can do it with whatever > version he prefers. I mean how do you check the signature if the user did run custom-cd? How do we support security against tempering that way? -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2004-02-09 01:11:21
|
Friedrich Lobenstock wrote: > Heiko Zuerker wrote on 08.02.2004 20:46 MET: > >> Friedrich Lobenstock wrote: >> >>> Bruce Smith wrote on 08.02.2004 17:50 MET: >>> >>>>> The update must be signed (pgp) and performed from within initrd, >>>>> that's the easy part. >>>>> >>>>> My original idea was to add the iso image as boot.cd.new to the >>>>> root of the media and then just check for it's existence, verify >>>>> it, rename it to bootcd.iso and continue. >>>> >>>> >>>> >>>> >>>> >>>> So, the USB stick has to be large enough to hold TWO copies of the ISO? >>> >>> >>> >>> >>> Hmmm...yes we can not overwrite the current ISO as it is currently >>> mounted. What if we go back to load everything into memory? Then >>> we could just replace the ISO on the memory stick (incl. its >>> signature file) in place. What is cheaper? RAM or USB-Memory sticks? >> >> >> >> That would require hundreds of MBs. I would say if somebody wants to >> use this feature, he has to provide the necessary space on this stick >> or whereever it is on. >> >>> BTW how do we handle the ISOs created with custom-cd? >> >> >> >> Since the User will replace the ISO himself, he can do it with >> whatever version he prefers. > > > I mean how do you check the signature if the user did run custom-cd? > How do we support security against tempering that way? Actually the user has to provide his own key pair. It's like the signing of the etc.tar.bz2, the user has to burn his own public key onto the ISO with custom-cd. Heiko |
|
From: Diego T. <dt...@co...> - 2004-02-09 18:35:24
|
On Sun, Feb 08, 2004 at 08:10:10PM -0500, Heiko Zuerker wrote: > >I mean how do you check the signature if the user did run custom-cd? > >How do we support security against tempering that way? > > Actually the user has to provide his own key pair. It's like the signing > of the etc.tar.bz2, the user has to burn his own public key onto the ISO > with custom-cd. i've been very busy and out for a while. is this gpg stuff configurable (with other words, can i take this feature off a custom build? :) -- -- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC 2327 7CD0 DD91 B09D 5799 -- Use of a keyboard or mouse may be linked to serious injuries or disorders. Diego Torres - dtorres at anthalia dot org - Madrid / España |
|
From: Heiko Z. <he...@zu...> - 2004-02-08 19:46:16
|
Bruce Smith wrote: >>I need to implement the option of remotely updating DL when it's on a >>USB stick or something. >> >>So far I couldn't really decide how I want to do this, so it's reliable >>and most of all secure. >> >>The update must be signed (pgp) and performed from within initrd, that's >>the easy part. >> >>My original idea was to add the iso image as boot.cd.new to the root of >>the media and then just check for it's existence, verify it, rename it >>to bootcd.iso and continue. > > So, the USB stick has to be large enough to hold TWO copies of the ISO? Yes correct. >>The major problem is that it's easy to temper with the verification of >>the signature, by replacing the initrd on the memory stick. > > > You could put the sig on a secure location on the internet instead of on > the media. But then initrd would need the network up. :-( That's then still the same problem, since initrd would need to verify itself, which doesn't make much sense. Heiko |
|
From: Friedrich L. <fl...@fl...> - 2004-02-08 20:17:30
|
Heiko Zuerker wrote on 08.02.2004 20:43 MET: > Bruce Smith wrote: > >>> I need to implement the option of remotely updating DL when it's on a >>> USB stick or something. >>> >>> So far I couldn't really decide how I want to do this, so it's >>> reliable and most of all secure. >>> >>> The update must be signed (pgp) and performed from within initrd, >>> that's the easy part. >>> >>> My original idea was to add the iso image as boot.cd.new to the root >>> of the media and then just check for it's existence, verify it, >>> rename it to bootcd.iso and continue. >> >> >> So, the USB stick has to be large enough to hold TWO copies of the ISO? > > > Yes correct. > >>> The major problem is that it's easy to temper with the verification >>> of the signature, by replacing the initrd on the memory stick. >> >> >> >> You could put the sig on a secure location on the internet instead of on >> the media. But then initrd would need the network up. :-( > > > That's then still the same problem, since initrd would need to verify > itself, which doesn't make much sense. Then checking a signature of the iso does not make any sense either if the initrd is tampered with. This seems to be a hen-and-egg problem. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2004-02-09 01:15:16
|
Friedrich Lobenstock wrote: > Heiko Zuerker wrote on 08.02.2004 20:43 MET: > >> Bruce Smith wrote: >> >>>> I need to implement the option of remotely updating DL when it's on >>>> a USB stick or something. >>>> >>>> So far I couldn't really decide how I want to do this, so it's >>>> reliable and most of all secure. >>>> >>>> The update must be signed (pgp) and performed from within initrd, >>>> that's the easy part. >>>> >>>> My original idea was to add the iso image as boot.cd.new to the root >>>> of the media and then just check for it's existence, verify it, >>>> rename it to bootcd.iso and continue. >>> >>> >>> >>> So, the USB stick has to be large enough to hold TWO copies of the ISO? >> >> >> >> Yes correct. >> >>>> The major problem is that it's easy to temper with the verification >>>> of the signature, by replacing the initrd on the memory stick. >>> >>> >>> >>> >>> You could put the sig on a secure location on the internet instead of on >>> the media. But then initrd would need the network up. :-( >> >> >> >> That's then still the same problem, since initrd would need to verify >> itself, which doesn't make much sense. > > > Then checking a signature of the iso does not make any sense either > if the initrd is tampered with. This seems to be a hen-and-egg problem. > At least we could use it to check that the new ISO image is valid and there were no transfer errors. Heiko |
|
From: Bruce S. <bw...@ar...> - 2004-02-09 00:00:46
|
> >>My original idea was to add the iso image as boot.cd.new to the root of > >>the media and then just check for it's existence, verify it, rename it > >>to bootcd.iso and continue. > > > > So, the USB stick has to be large enough to hold TWO copies of the ISO? > > Yes correct. Is anyone ever going to use the feature? 1GB sticks are EXPENSIVE!!! What about automatically updating the stick from CD? Burn the new image on CD, boot from CD, and it copies itself to the USB stick. It could also be used to initially create a bootable stick (blank). Just a thought, CD drives are a LOT cheaper than big memory sticks. - BS |
|
From: Friedrich L. <fl...@fl...> - 2004-02-09 00:20:01
|
Bruce Smith wrote on 09.02.2004 01:00 MET: >>>>My original idea was to add the iso image as boot.cd.new to the root of >>>>the media and then just check for it's existence, verify it, rename it >>>>to bootcd.iso and continue. >>> >>>So, the USB stick has to be large enough to hold TWO copies of the ISO? >> >>Yes correct. > > > Is anyone ever going to use the feature? 1GB sticks are EXPENSIVE!!! > > What about automatically updating the stick from CD? Burn the new image > on CD, boot from CD, and it copies itself to the USB stick. It could > also be used to initially create a bootable stick (blank). > > Just a thought, CD drives are a LOT cheaper than big memory sticks. What if it boots of off the USB stick, checks for an "update-CD" (just a normal CD, but created from a newer ISO), does an update if necessary and then moves one? Eg. tell the on-site operator (secretary or whoever is able to help you) to burn the CD put it in the machine, reboot it and after it's back up again remove the CD. If you boot from CD it would possibly mount the ISO from there and you can't remove the disc till the next reboot. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2004-02-09 00:28:37
|
> > What about automatically updating the stick from CD? Burn the new image > > on CD, boot from CD, and it copies itself to the USB stick. It could > > also be used to initially create a bootable stick (blank). > > > > Just a thought, CD drives are a LOT cheaper than big memory sticks. > > What if it boots of off the USB stick, checks for an "update-CD" (just a > normal CD, but created from a newer ISO), does an update if necessary and > then moves one? Sure, if that can be done. I was worried about problems updating a running system (replacing libraries in use, etc.), which is why I suggested booting off CD. - BS |
|
From: Friedrich L. <fl...@fl...> - 2004-02-09 00:48:03
|
Bruce Smith wrote on 09.02.2004 01:28 MET: >>>What about automatically updating the stick from CD? Burn the new image >>>on CD, boot from CD, and it copies itself to the USB stick. It could >>>also be used to initially create a bootable stick (blank). >>> >>>Just a thought, CD drives are a LOT cheaper than big memory sticks. >> >>What if it boots of off the USB stick, checks for an "update-CD" (just a >>normal CD, but created from a newer ISO), does an update if necessary and >>then moves one? > > > Sure, if that can be done. I was worried about problems updating a > running system (replacing libraries in use, etc.), which is why I > suggested booting off CD. It has to be done in the initrd anyway and you are not changing those libraries when doing the update. And yes this might be a problem of its own, we can not change the initrd anymore. Hmmmmm.....then initrd needs some fixed parts (does not change across stable version) which loads the varibale ones, taking into account to update those if an "update CD" exists. Then the rest of the system is updated. Now this might also be a good idea to include the update script _from_ CD. This way we can provide for a more complicated if we did not think about a specific update problem later and as this script is tamper proof (on CD!) it can check all the signatures against a provided signature file (is that really needed?). Sounds to get complicated. What do you think? -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Friedrich L. <fl...@fl...> - 2004-02-09 00:53:06
|
Friedrich Lobenstock wrote on 09.02.2004 01:47 MET: > Bruce Smith wrote on 09.02.2004 01:28 MET: > >> Sure, if that can be done. I was worried about problems updating a >> running system (replacing libraries in use, etc.), which is why I >> suggested booting off CD. > > > It has to be done in the initrd anyway and you are not changing those > libraries when doing the update. And yes this might be a problem of its > own, we can not change the initrd anymore. Hmmmmm.....then initrd needs > some fixed parts (does not change across stable version) which loads the > varibale ones, taking into account to update those if an "update CD" > exists. Then the rest of the system is updated. Now this might also be a > good idea to include the update script _from_ CD. This way we can > provide for a more complicated if we did not think about a specific > update problem later and as this script is tamper proof (on CD!) it can > check all the signatures against a provided signature file (is that > really needed?). > > Sounds to get complicated. What do you think? Maybe I'm just over-complicating things here... -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2004-02-09 01:25:22
|
Friedrich Lobenstock wrote: > Bruce Smith wrote on 09.02.2004 01:28 MET: > >>>> What about automatically updating the stick from CD? Burn the new >>>> image >>>> on CD, boot from CD, and it copies itself to the USB stick. It could >>>> also be used to initially create a bootable stick (blank). >>>> >>>> Just a thought, CD drives are a LOT cheaper than big memory sticks. >>> >>> >>> What if it boots of off the USB stick, checks for an "update-CD" >>> (just a normal CD, but created from a newer ISO), does an update if >>> necessary and then moves one? >> >> >> >> Sure, if that can be done. I was worried about problems updating a >> running system (replacing libraries in use, etc.), which is why I >> suggested booting off CD. > > > It has to be done in the initrd anyway and you are not changing those > libraries when doing the update. And yes this might be a problem of its > own, we can not change the initrd anymore. Hmmmmm.....then initrd needs > some fixed parts (does not change across stable version) which loads the > varibale ones, taking into account to update those if an "update CD" > exists. Then the rest of the system is updated. Now this might also be a > good idea to include the update script _from_ CD. This way we can > provide for a more complicated if we did not think about a specific > update problem later and as this script is tamper proof (on CD!) it can > check all the signatures against a provided signature file (is that > really needed?). Since all update functions are on the CD anyway (pre_init script), the existance of this script would be the only requirement. This would be the procedure: 1. initrd loads 2. initrd replaces bootcd.iso with bootcd.iso.new (after verifying it) 3. initrd continues as usual 4. pre_init sees the CD version is different to the config version and performs an update (interactive part already implemented). I didn't think to much about the upgrade script yet, but that's a separate issue. Heiko |
|
From: Friedrich L. <fl...@fl...> - 2004-02-09 08:12:59
|
Heiko Zuerker wrote on 09.02.2004 02:20 MET: > Friedrich Lobenstock wrote: > >> It has to be done in the initrd anyway and you are not changing those >> libraries when doing the update. And yes this might be a problem of >> its own, we can not change the initrd anymore. Hmmmmm.....then initrd >> needs some fixed parts (does not change across stable version) which >> loads the varibale ones, taking into account to update those if an >> "update CD" exists. Then the rest of the system is updated. Now this >> might also be a good idea to include the update script _from_ CD. This >> way we can provide for a more complicated if we did not think about a >> specific update problem later and as this script is tamper proof (on >> CD!) it can check all the signatures against a provided signature file >> (is that really needed?). > > > Since all update functions are on the CD anyway (pre_init script), the > existance of this script would be the only requirement. > > This would be the procedure: > 1. initrd loads > 2. initrd replaces bootcd.iso with bootcd.iso.new (after verifying it) > 3. initrd continues as usual > 4. pre_init sees the CD version is different to the config version and > performs an update (interactive part already implemented). What do you do if initrd has to be updated? -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2004-02-09 01:16:23
|
Bruce Smith wrote: >>>>My original idea was to add the iso image as boot.cd.new to the root of >>>>the media and then just check for it's existence, verify it, rename it >>>>to bootcd.iso and continue. >>> >>>So, the USB stick has to be large enough to hold TWO copies of the ISO? >> >>Yes correct. > > > Is anyone ever going to use the feature? 1GB sticks are EXPENSIVE!!! I know somebody who wants to use it. Don't forgett that with the zisofs the size of DL decreased quite a bit. > What about automatically updating the stick from CD? Burn the new image > on CD, boot from CD, and it copies itself to the USB stick. It could > also be used to initially create a bootable stick (blank). > > Just a thought, CD drives are a LOT cheaper than big memory sticks. It needs to be done remotely, there are no moving parts in the computers and nobody available to actually do the task. Heiko |
|
From: Friedrich L. <fl...@fl...> - 2004-02-08 17:10:49
|
Heiko Zuerker wrote on 08.02.2004 16:21 MET: > The major problem is that it's easy to temper with the verification of > the signature, by replacing the initrd on the memory stick. Then initrd needs to check its own signature first. If this does not check out - hold the damned thing so the users _has to_ manually intervene. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2004-02-08 19:51:22
|
Friedrich Lobenstock wrote: > Heiko Zuerker wrote on 08.02.2004 16:21 MET: > >> The major problem is that it's easy to temper with the verification of >> the signature, by replacing the initrd on the memory stick. > > > Then initrd needs to check its own signature first. If this does not > check out - hold the damned thing so the users _has to_ manually > intervene. That's the way I'm gonna do it, when we don't find a better solution. This means that we have to trust that the system is secure, which I don't really like. The main problem is that when somebody gains access to the host, he can replace the initrd, without any problems, with his own version... Heiko |
|
From: Friedrich L. <fl...@fl...> - 2004-02-08 20:19:06
|
Heiko Zuerker wrote on 08.02.2004 20:50 MET: > Friedrich Lobenstock wrote: > >> Heiko Zuerker wrote on 08.02.2004 16:21 MET: >> >>> The major problem is that it's easy to temper with the verification >>> of the signature, by replacing the initrd on the memory stick. >> >> Then initrd needs to check its own signature first. If this does not >> check out - hold the damned thing so the users _has to_ manually >> intervene. > > > That's the way I'm gonna do it, when we don't find a better solution. > This means that we have to trust that the system is secure, which I > don't really like. > The main problem is that when somebody gains access to the host, he can > replace the initrd, without any problems, with his own version... Hmmmm.....what's this stuff M$ and the music industry wants in our PCs?... -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
