chmod should not be required

[adrelanos]

https://github.com/martincmelik/Securix-Linux/blob/master/securix-install/chroot.sh

# set chmod for securix scripts
chmod 0755 /usr/sbin/securix*
chmod -R 0600 /etc/securix
chmod -R 0665 /var/securix

 # checksec.sh
chmod u+x /usr/local/bin/checksec.sh

# iptables
chmod u+x /etc/conf.d/iptables.rules

I think these are unnecessary. When you set the desired permissions in the source tarball and/or git already, then copy those files, permissions are preserved. That would help simplify the code some more.

[martinholovsky]

Hi, as it seems that in future git will be used for installation, is there a chance that git repository can preserve permissions? So when I will use git clone, it will be downloaded together with rwx?
If not, then we cant use it

[adrelanos]

Git preserves permissions by default. If you change permissions, git recognizes it as changed file. And the permission change should be committed. In short: git does this perfectly.

[martinholovsky]

Doesnt seems to be correct, according to this
https://stackoverflow.com/questions/13275000/how-do-you-use-git-cache-meta
and this
https://stackoverflow.com/questions/3207728/retaining-file-permissions-with-git
git-cache-meta has to be used

nevertheless until installer will be using git, I cant remove it

[adrelanos]

Indeed. I was wrong. Git only stores the executable bit. All I needed and used until now.

I think requiring users to also install and set up git-cache-meta would be a usability issue and therefore a bad idea.

For checksec.sh and iptables.rules I'd say, just set them "chmod +x" in git. Nevermind if non-root users can execute these scripts also. Non-root users cannot change iptables rules anyhow, so a fine grained executable bit does not improve security. And checksec.sh is something that any compromised user account can create itself anyhow. So no reason to not have it executable for everyone in the first place.

[martinholovsky]

ok, I will leave this issue open, but it will be solved after installation via github will be implemented

[martinholovsky]

Hi,
git binary is not available on gentoo livecd... Im more and more thinking about my own live CD as Gentoo ones is limited in many ways, but I think that community will consider it as untrusted, right? Is there a way how to avoid that?

[adrelanos]

git is available on the full DVD. (#50)

but I think that community will consider it as untrusted, right?

Yes.

Is there a way how to avoid that?

Maybe if it's deterministic. But that's probably a unrealistic goal.

[martinholovsky]

Gentoo team will not add it into minimal cd, trying now push it into admin cd

[martinholovsky]

What about to use gentoo minimal iso and just add few more applications by script like this (https://forums.gentoo.org/viewtopic-t-580369-start-0.html). Script will be available for anyone and even build log can be included inside iso image so it could be reproduced...?

[adrelanos]

Will the iso be deterministic? I mean, can everyone who follows the instructions, i.e. 1) download original gentoo iso 2) run script to add the file 3) show sha512 hash of newly created iso. Will it match for everyone doing these steps?

[adrelanos]

After thinking more about this... I think the overall idea... If I understood this right... "Because the original gentoo minimal dvd does not come with git, to install from source, you either have to use the huge binary blob (the custom iso) or you have to create your own first. Then boot from this dvd, so you can use git to download the rest of the source code so you can finally install securix." Sounds rather cumbersome.

Alternative, more unified approaches.....

---

a) gentoo admin dvd, upstream, git

If the admin dvd is minimal enough and they add git to it, problem would be solved?

---

b) tar.xz for gentoo minimal dvd users

1. Add a script that can create a deterministic tar.xz from current git revision. (Again, deterministic means here, anyone who repeats that step from that revision will end up with the same check sum.) (I know the required tar command line options.)
2. Upload that tar.xz. Perhaps sign it using some way.
3. Tell users of gentoo minimal dvd users to download, verify, extract it. Then they can run the installer. Others still have the freedom to create that deterministic tar.xz themselves and upload it wherever they wish.
4. People using full live dvd have the option to download the code using git or using the tar.xz.

---

c) securix installer dvd

1. Have a working gentoo system as prerequisite as build environment.
2. let them obtain the securix source code via git (and/or other methods)
3. have instructions on how to create such a securix installer dvd from source
4. tell them to boot that securix installer dvd
5. tell them to start that installer [or auto start it]
   eventual bonus feature that needs code 1) mixed securix installer + securix live dvd
   eventual bonus feature that needs code 2 ) other linux [debian] or any linux would suffice as build prerequisite

By doing this in a modular fashion, the feature "Bootable Raw / Virtual Machine Image Creation" #98 could still be added later. For this purpose, I would advice not touching installer.sh / chroot.sh a lot and to have a separate dvd creation utility.

---

Not sure how urgently you want (c) your own DVD. Obviously method (a) and (b) require far less work.

[martinholovsky]

Git client will be added into Gentoo admincd, so Im fine with that, it might just take few more weeks