Add security checks #488

[skyrider223]

Hello,

Actually, i’m working on a usable FOS client working on Secure Boot, based on signed Clonezilla Linux kernel.
(with GRUB-signed + shim for PXE chainloading)

In a attempt of make a wrapper for GRUB (like bootmenu.class.php), i discovered in bootmenu.class.php :

Everybody on the network where FOG Server is connected (even if the server is connected on Internet) can

• Delete a host
• Update a product key
• Join a multicast session
• Approve a host (which can lead to an AD credential leak)

The only prerequisites are to known the mac address of a computer present in the FOG Database.

In the commit proposed, it changes the behavior of how iPXE handles the user and password throughout multiples #iPXE scripts, and ensures at all times an action is authenticated, event if the command is “internal” (delconf/sessname/key/aprvconf)

Theses lines ensures username and password parameters to be kept in RAM during the iPXE phase && re-transmitted (if defined):

'param username ${username}',
'param password ${password}',

PS : I’m sorry @Sebastian-Roth for my (very) late reply.

https://github.com/FOGProject/fogproject/pull/488

[george1421]

@skyrider223 said in Add security checks #488:

Delete a host
Update a product key
Approve a host (which can lead to an AD credential leak)

IMO these functions should be removed from the FOG iPXE menu completely (password or not). These processes should be restricted to the FOG UI. Simply for the fact you stated that changes to the FOG environment could be done in a malicious and anonymous way with this code hanging around.

In regards to the other method using the ubuntu/debian kernel (I believe that is what clonezilla live does) the issue is with the drivers. Most of those general purpose kernels use dynamically loaded drivers. That would work for FOG, but then the drivers would need to be loaded into the init.xz (VHD). Both methods are possible. I was testing a few years ago with just this solution of using grub and the shim to secure boot and it did work at the time. But the project fell out of focus and then when I got back to it it was failing. The issue I ran into with Grub is that its not dynamic enough for FOG. You can do static pxe booting, but the issues came at the deploy image menu to get that bit to work.

[Sebastian Roth]

@skyrider223 Thanks heaps for posting in the forums. Unfortunately there was not much of a discussion going on.

So should we add security checks or even remove the entries from the menu altogether? I tend to add the checks.

[Tom Elliott]

@sebastian-roth et al.

The reason these items were added were specifically because of requests. Especially those onestop shops where one might not have direct access to the UI for security, or remote possibilities.

Working with that I tend to side with the idea of making the menu prompt for user/pass for every action that should ultimately have authentication.

Don’t know why I missed that and for that I’m sorry.

Just notes:

Delete a host - Not quite sure why this is fully required and I would almost say it should not be on the menu.
Update a product key - This I think could be handy if say you have a generic keyed image but wanted to use an elevated product key for certain VIP machines. While you could do this from the UI, I guess it was just requested because people don’t like having to load a UI sometimes?
Join a multicast session - This one I think definitely should be password protected and hopefully this one at least makes sense to have on the menu.
Approve a Host -This should be UI specific I suppose.

Hopefully this helps.

[Sebastian Roth]

Thanks everyone for the comments on this. Looks like we better remove “Delete a host” and “Approve a Host” from the iPXE menu altogether.

With the “Update a product key” I see different opinions. While I understand your point @Tom-Elliott I am wondering if people actually use this at all because typing a 25 character key right at the machine is not much convenient. But on the other hand I think adding the security check should be enough to prevent from malicious/anonymous user inputs which @george1421 mentioned. I tend to leave that option in the menu but secure it - and same for “Join a multicast session”.

@skyrider223 I just merged your pull request and opened a new issue to take care of removing the menu items as discussed. I added a list of code changes needed to the issue report already. Are you keen to look into this as well?