Skip Bitlocker detection?

[gwhiteia]

I know the general thought is that Bitlocker should be disabled prior to imaging, but we’ve done it using CloneZilla and had no issues.

CloneZilla captures the partitions it knows about in their native filesystems, and then does the BL’ed partition as RAW…it doesn’t force us to do the whole drive as RAW.

Could the developers perhaps add that functionality as a switch in the image definition - Skip Bitlocker detection - yes/no?

I love the product, but I can’t use it without this feature.

Thanks!

[Tom Elliott]

FOG already has the capability to do this, but we added a check because that was the “thought” we needed to do.

You can modify the file yourself.

You are, hopefully, familiar with postinit scripts:

The file you’ll want to replace is:
/usr/share/fog/lib/funcs.sh

The line you would need to comment:
Line 290 in fsTypeSetting function.

You should then have the ability to capture/deploy images using the “imager/raw” method.

[gwhiteia]

That’s awesome…thanks Tom!

Is that something that could be incorporated into the web interface? Perhaps in the definition of the image?

[george1421]

@gwhiteia said in Skip Bitlocker detection?:

know the general thought is that Bitlocker should be disabled prior to imaging, but we’ve done it using CloneZilla and had no issues.

I question this statement and then question the value of bitlocker if you can do this successfully. As long as you are using the tpm chip there should be no value in cloning a bitlocker protected partition unless it will be used to restore back to the same computer. If you are doing a one to many deployment with this image it should fail on every computer you deploy it to because the certificate held in the tpm chip will not match. If you can do this then something is wrong with bitlocker.

@Tom-Elliott

The file you’ll want to replace is:
/usr/share/fog/lib/funcs.sh

The line you would need to comment:
Line 290 in fsTypeSetting function.

Could we key the skip that line if a specific kernel parameter exists in FOG 1.6.x? I can see the value in having this check to keep the fog admin from doing something they don’t expect. But if the FOG admin “really” wants to do this a kernel parameter flag could be a way to bypass the check.

[Tom Elliott]

@gwhiteia Sure it could be, but I think, for now, this change would be more quickly incorporated using postinit scripts.

This is because, the change would require 2 steps.

1. The GUI: This element is extremely easy to add. A simple change to the SQL schema and a little HTML code.

2. The FS/FOS/INIT rebuild: This element, while not difficult to add, requires a rebuild of the init’s. This takes some time to accomplish, (Think usually around 3 hours assuming no issues during the build.)

So, we can add this level of functionality, and I imagine we probably will in the future. When that will be, I can’t really say. But Postinit’s add levels of functionality and, presumably, understanding of the backend code which I think would be useful as well.

Please see https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins?_=1601327523120 in regards to how to use postinit scripts if you need some help.

[Tom Elliott]

@george1421 I think the capture task could have a “allow bitlocker capture” or something similar, along the same lines as “Schedule as debug” task.

This could be interpretted as a kernel arg.

This would be extremely simple and require no Schema change at least.

Thanks for letting me think it through.

The only change is a minor GUI addition and a little change to the Init fsType script.

I don’t think we need to worry about bitlocker on a deploy task.

[george1421]

@Tom-Elliott said in Skip Bitlocker detection?:

postinit scripts

I thought about postinits, but then I wondered of we slide in a new func.sh script, isn’t that already loaded into memory before the postinit code is called? I think the OP is going to need to unpack the inits make the change and then repack them. https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image

It would be really nice if it could be done in a postinit script but I think its too late by the time the postinit stuff is called.

[george1421]

@Tom-Elliott said in Skip Bitlocker detection?:

The only change is a minor GUI addition and a little change to the Init fsType script.

Do you want me to put in a request for this so we can track it?

[Tom Elliott]

@george1421 the postinit could re source the funcs file at the end.

[Tom Elliott]

@george1421 sure! At least then there’s a way to track.

[Sebastian Roth]

@george1421 said in Skip Bitlocker detection?:

I question this statement and then question the value of bitlocker if you can do this successfully. As long as you are using the tpm chip there should be no value in cloning a bitlocker protected partition unless it will be used to restore back to the same computer. If you are doing a one to many deployment with this image it should fail on every computer you deploy it to because the certificate held in the tpm chip will not match. If you can do this then something is wrong with bitlocker.

@gwhiteia Can you please comment on this before we go ahead and change things. This is the basis on why we added the bitlocker check as a hard break in the scripts instead of making it optional. Do you use bitlocker without TPM or how does it work in your case?

[gwhiteia]

@george1421 said in Skip Bitlocker detection?:

@Tom-Elliott said in Skip Bitlocker detection?:

The only change is a minor GUI addition and a little change to the Init fsType script.

Do you want me to put in a request for this so we can track it?

Yes, please

[gwhiteia]

@Sebastian-Roth said in Skip Bitlocker detection?:

@george1421 said in Skip Bitlocker detection?:

I question this statement and then question the value of bitlocker if you can do this successfully. As long as you are using the tpm chip there should be no value in cloning a bitlocker protected partition unless it will be used to restore back to the same computer. If you are doing a one to many deployment with this image it should fail on every computer you deploy it to because the certificate held in the tpm chip will not match. If you can do this then something is wrong with bitlocker.

@gwhiteia Can you please comment on this before we go ahead and change things. This is the basis on why we added the bitlocker check as a hard break in the scripts instead of making it optional. Do you use bitlocker without TPM or how does it work in your case?

Yes, we use BL without the TPM

[Sebastian Roth]

@gwhiteia said in Skip Bitlocker detection?:

Yes, we use BL without the TPM

But how?

[gwhiteia]

@Sebastian-Roth said in Skip Bitlocker detection?:

@gwhiteia said in Skip Bitlocker detection?:

Yes, we use BL without the TPM

But how?

We disable TPM in the BIOS prior to building our image and modify a few GPO settings to use passwords instead of PINs

[george1421]

@Sebastian-Roth said in Skip Bitlocker detection?:

But how?

If you run bitlocker without TPM you have an option to use a usb key with the certificate installed or with a preboot password that is managed by the uefi boot loader. It is surely not as secure at the tpm route, but if you have no option, you have limited choices.

Some countries may mandate to not use tpm protection.

[Sebastian Roth]

@george1421 @gwhiteia Ok, so essentially it means we should not error out when detecting bitlocked partitions. But then we will end up with more people asking why their image is so big.

Printing a warning is of no use because it Just skips past with no one noticing it.

[george1421]

@Sebastian-Roth The idea as I understand it, there should be a one time flag (akin to debug flag and location) that will allow the FOG Admin to bypass the check. This is for a one-off situation. 99% of the time its proper to warn the FOG Admin that bitlocker is on and he/she should disable it first. For that remaining 1% of the time of the FOG Admin wants to bypass this stop the FOG should let them (i.e. play with matches and a stick of dynamite. “What could go wrong??”)

[Sebastian Roth]

@george1421 Yeah, you are right. I forgot about this part earlier being discussed here in this topic. We shall look into adding this.

[Tom Elliott]

@Sebastian-Roth, @george1421

I have added this “Feature” to 1.6 branch.

I have not added the code to the fos engine stuff, as I’ll leave that up to whomever is building them right now. I don’t have a build environment and we don’t have automated building setup yet (that I am aware of at least)

https://github.com/FOGProject/fogproject/commit/bff919e655d9a239040133466874b19c82562bf9

Essentially, I added the checkbox to bypass bitlocker detection when a capture task is selected. It uses Scheduled Task other5 field to store if this was set or not, and creates a new column for setting this flag in the task.

When this flag is set, it sets the kernel arg bitlockerbypass=1 making it easy enought to look for in the bitlocker check function.

Let me know if you have any other questions.