Good day! Sorry for long absence - my job takes too much time ;)
(Robert Millan) > hope not.. but then again, I don't like making myself an opinion on >something >before I hear what it is.
>Oleg, please can you clarify what you intend to do?
Yep, Uwe Hermann was in the right about Grub Security Modules destiny :) I'll try to describe in a few words their main ideas:
* registered users dividual sturtup config (e.g. we have initial grub.cfg
that e.g. calls login command, that e.g. :) takes user login and get ${login}.cfg, where we can find password command with password hash argument)
grub.cfg: ... login ...
if user chose MyLogin login, we start
MyLogin.cfg:
* all config files signing (during installation procedure, i think) and verification during boot (e.g. we have connected files
grub.cfg and grub.cfg.sign files, where the second one is a signature). i'm gonna use RSA DS algo.
* additional OS-connected verification in user config we can include special checking (e.g. call md5 FILE CORRECT_HASH_VALUE) to prevent OS-valuable files modification.
* special security log keeping all security-connected operations leave a mark on system journal (via journal.mod)
///////// What i've done already: * md5 file hash checking * RSA DS code porting from rsaref lib (but it's not license-correct, so i'll try to make this code myself)
* log operating module (partly). I'm not a FS-specialist, so i can enbug only ext2 write ability. IMHO we really need FS-write (not only block write, but file write) in grub2.
////////
Problems: I've met only one problem:
grub2 core.img verification (we need this to make another types of verification reasonable) This can be done:
////////
1st way - using BIOS extentions - it's a hot topic to discuss cause e.g. my MB ASUS A8N BIOS do not have such one :(
M.b. in future situation will be much better 2nd way - think that grub core.img is de facto allright M.b. it's not so bad. 3rd way - let's think :)