-
Notifications
You must be signed in to change notification settings - Fork 145
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
31ccecb
commit d3fd055
Showing
1 changed file
with
5 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @tschettervictor happy holidays, This change will not make the MAC more random, it will just change the HASH result still remaining static.
If you meant to change/randomize a new MAC address for a jail with the same name even after re-creation for added security, you need to also randomize either a prefix/postfix in between the jail name in order to always get a fresh MAC address if the user want that behavior, hence this should be an user selection option, for example look at the mere basic example below:
Look at the above pattern on how the MAC address does remains the same on the first 3 attempts, so the prefix for the "${external_interface}" is really not needed, but rather a random number generation in conjunction with the jail name.
Be aware that the above example is just a quick hack to show the wanted behavior and that
mktemp
creates a temporary file, so this cannot be used without code to remove this file after MAC generation, another/better approach is to generate a random number based on the hardware then using such variable for said purpose among other ways.Regards!
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that.
My goal is ultimately to have a MAC that will always be the same for a jail with the same name. The issue I had was that when interfaces were created by the host named "bridge0 bridge1 bridge2" etc.. the prefix for these would always be the same because the system creates MAC addresses for bridge interfaces where only on number is different (see below). I've also recently added PR #783 that allows you to add interfaces to jails. With this change, a jail linked to bridge0 would have the same mac on two interfaces if bridge1 is added.
But with the implementation I currently have, the MAC of the host interface is hashed for the first six digits, then the jail name for the last six. I am not so concerned with randomization as I am with the "static" part. Meaning a jail with the same name on the same interface should always have the same MAC.
Notice that in the following, only the last 2 digits are different. I think hashing the full MAC of the host interface will give the best balance of "static" "security and "randomization".
EDIT: I've also now changed so the section you commented on above is not what it currently looks like. See the updated version...
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @tschettervictor, I understand now your case scenario on multiple Jails with the same name now and I think we talked about this before while I was busy, since one of the
bastille
goals is keep an easy to use yet highly secure/customizable Jail manager, this should be an user selectable option i.e:--static-mac
when user creates a Jail requesting for a static MAC for ease of management while keep MAC random(the default) for the average user for added security, really sorry if this is already an user option.Sorry I've been busy to stay up to date on all
bastille
changes but I will get a break asap in order to revise the code on the ZFS stuff and overall consistency/compatibility/cleanup.Happy new year!
Regards!
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will have to discuss it some more.
We could have a -m switch for it.
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could very easily be achieved, but it would require an additional two blocks inside the “generate_vnet_block” function. Easily managed I’m sure, I’m just not convinced as to the need of it. But for security, you are right that I would be better.
I’ll try to implement this change once my last few PRs are merged.
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have this implemented in my fork now. Simply add -M|--static-mac to options when creating to have a statically assigned Mac based on the IF name and jail name.
Will clean up the code and request another PR shortly.
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, also fyi handling/combining of multiple --long-options can be easily implemented with something like the below example:
Another example with unnecessary white spaces in between the options handled by
xargs
:Then the error handling code takes care of misspelled options and/or for options who can't live together.
Regards!
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whitespace isn’t really an issue. I just tried and everything worked as expected. My biggest goal was to allow for “-fsm” etc… (bunching short options together)
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right only handling multiple short options is enough and keep the
case
/esac
code smaller/cleaner, the user can always explicitly select--long-option
for special/advanced commands without short/single character option.Regards!
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more question before I let you go on this one.
Should we keep it as is like the following...
Or shorten it like the second block?
The second is shorter, but seems harder to follow.
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, the first block while a little larger, its ident is more readable and easier to follow as you said, also the too short variable
_o
should be renamed to something more meaningful like_opt
as well.Regards!
d3fd055
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noted. Thanks.