#1278 PR `closed`: Change default Permission on Files and Directory in tftpboot.¶

Labels: enhancement, won't fix / can't fix / obsolete, minor bug

schabrolles opened issue at 2017-04-04 14:23:¶

Files and directories created for PXE/TFTP are too restricted (500 or 400 with owner root) which prevent them to be accessible during tftp/bootp process.
This is mostly due to the default umask 0077 set in 010_set_umask.sh

before:

[root@rhel72be-177 rear]# ls -ld sles11sap-144
total 8
drwxr-x--- 2 root root 4096 Apr  4 16:15 sles11sap-144

[root@rhel72be-177 rear]# ls -l sles11sap-144
total 100880
-rw------- 1 root root      516 Apr  4 16:15 README
-rw------- 1 root root      540 Apr  4 16:15 rear-sles11sap-144
-rw------- 1 root root  2925256 Apr  4 16:15 rear-sles11sap-144.log
-r-------- 1 root root 36048732 Apr  4 16:15 sles11sap-144.initrd.cgz
-r-------- 1 root root 20806910 Apr  4 16:15 sles11sap-144.kernel
-r-------- 1 root root      294 Apr  4 16:15 sles11sap-144.message
-rw------- 1 root root      294 Apr  4 16:15 VERSION

I just propose two light modifications:

Force creation of output directory $opath in 755 when OUTPUT=PXE and protocol is NFS.
Use cp -p to preserve permission and avoid umask 0077 permission.

after:

[root@rhel72be-177 rear]# ls -ld sles11sap-144
total 8
drwxr-xr-x 2 root root 4096 Apr  4 16:15 sles11sap-144

[root@rhel72be-177 rear]# ll sles11sap-144
total 101776
-rw------- 1 root root      516 Apr  4 16:12 README
-rw-r--r-- 1 root root      540 Apr  4 16:12 rear-sles11sap-144
-rw------- 1 root root  2925288 Apr  4 16:12 rear-sles11sap-144.log
-r--r--r-- 1 root root 36048256 Apr  4 16:12 sles11sap-144.initrd.cgz
-r--r--r-- 1 root root 20806910 Jun 24  2015 sles11sap-144.kernel
-r--r--r-- 1 root root      294 Apr  4 16:12 sles11sap-144.message
-rw------- 1 root root      294 Apr  4 16:12 VERSION

jsmeix commented at 2017-04-05 07:21:¶

@gdha
could you also have a look?

In general I think there should be no problem
when the ReaR recovery system (e.g. its kernel
and initrd or an ISO file) is generally accessible
because as far as I remember what @schlomo
had written somewhere a longer time ago
the ReaR recovery system should not contain
confidential stuff (like passwords or user data).
As far as I know confidential or private stuff
is only in the backup.

jsmeix commented at 2017-04-05 08:49:¶

@gozora
could you also have a look?

My general question to you is whether or not
in case of UEFI the ReaR recovery system
may contain confidential stuff?
I am not at all a UEFI expert but when I think
about "UEFI" I also think about "Secure Boot"
and perhaps in case of UEFI + Secure Boot
the ReaR recovery system may contain
confidential stuff?
This particular case here is about PXE/TFTP boot
but I don't know if UEFI could be also in use
for PXE/TFTP boot?

My basic concern is whether or not security issues
could arise when the files of the ReaR recovery system
(kernel + initrd or an ISO image) are generally accessible.

Or in other words:
As far as I see this pull request contradicts the comment in
output/default/010_set_umask.sh
and I wonder if an exception is really o.k. in this particular case.

gozora commented at 2017-04-05 09:18:¶

@jsmeix I don't see any security problem, until initrd and kernel are not public writeable.

This particular case here is about PXE/TFTP boot
but I don't know if UEFI could be also in use
for PXE/TFTP boot?

As far as I know PXE code is executed before UEFI, so for me this two technologies are independent (but I have zero experience with such setup).
UEFI have some "plugins" that can boot from DHCP, but again I've never played with them before.

V.

schabrolles commented at 2017-04-05 09:29:¶

@gozora, initrd and kernel are NOT public writeable.
here is an output of the result DIR with this patch:

[root@rhel72be-177 rear]# ll sles11sap-144
total 101776
-rw------- 1 root root      516 Apr  4 16:12 README
-rw-r--r-- 1 root root      540 Apr  4 16:12 rear-sles11sap-144
-rw------- 1 root root  2925288 Apr  4 16:12 rear-sles11sap-144.log
-r--r--r-- 1 root root 36048256 Apr  4 16:12 sles11sap-144.initrd.cgz
-r--r--r-- 1 root root 20806910 Jun 24  2015 sles11sap-144.kernel
-r--r--r-- 1 root root      294 Apr  4 16:12 sles11sap-144.message
-rw------- 1 root root      294 Apr  4 16:12 VERSION

Those files are created in mode 0444 in 800_copy_to_tftp.sh (line 37).
That's why I propose to use cp -p during 950_copy_result.sh to preserve this right access mode.

# files must be readable for others for PXE
chmod 444 "$PXE_TFTP_LOCAL_PATH/$PXE_KERNEL"
chmod 444 "$PXE_TFTP_LOCAL_PATH/$PXE_INITRD"
chmod 444 "$PXE_TFTP_LOCAL_PATH/$PXE_MESSAGE"

I don't know if there is any side-effect with this change, may be we can use this cp -p only when OUTPUT=PXE.
What do you think ?

gozora commented at 2017-04-05 09:46:¶

yes i know, it was(surprise surprise) a typo :).

jsmeix commented at 2017-04-05 09:55:¶

I asked a colleague and got the following basic idea:

Default access permissions via things like umask/chmod
are in practice only relevant for local user access.
For access via various network protocols it depends
on each network protocol whether or not local access
permissions have an effect.
Accordingly in practice it should not make things
really less secure for acces via network when the
local access permissions are more permissive.

jsmeix commented at 2017-04-05 10:06:¶

@gozora
as far as I read in
https://en.wikipedia.org/wiki/Preboot_Execution_Environment
PXE code is executed by BIOS or by the UEFI firmware.

As far as I understand it PXE code basically loads
a bootloader (PXELINUX in case of ReaR) and then
that bootloader loads kernel and initrd.

My concern in this particular case is not that ReaR files
are generally writable (which would also be an issue).

My concern is that ReaR files are generally readable
when ReaR files contain confidential or private stuff.

At least the ReaR backup contains confidential
(e.g. whatever keys - like for ssh access)
and private stuff (user data) and it is clear
that the user must protect his backup from
unintended access.

My question here is whether or not also other ReaR files
like kernel and initrd could contain confidential or private stuff.
In this case also other ReaR files would have to be protected
against unintended access.
It seems in general local access permissions are insufficient
to protect files against unintended access via various network
protocols.

gozora commented at 2017-04-05 10:33:¶

In general, I really can't say if ReaR restore/recovery system contains any private files. I'd guess that no.
If talking about UEFI related files, I think that it should be OK.
I've never studied secure boot very deeply but my general understanding is that you have signed kernel with private key (which is of course not part of image) and during boot it is compared against public keys with help of shim.efi (somehow). So no files that should really remain secret.

V.

jsmeix commented at 2017-04-05 11:43:¶

By default the ReaR recovery system should not contain
confidential or private stuff (as far as I remember what
@schlomo wrote a longer time ago) unless the user
explicitly configured something e.g. via COPY_AS_IS
and things like that (e.g. SSH_ROOT_PASSWORD).

But I think since
https://github.com/rear/rear/pull/1267
this is no longer true because now we have
by default in conf/GNU/Linux.conf

COPY_AS_IS=( ... /etc/ssl/certs/* /etc/pki/* )

where - as far as I understand it - in /etc/ssl/certs or
/etc/pki also self-generated private stuff could be stored.

schabrolles commented at 2017-04-12 16:37:¶

Hi guys,
Forget about this request. I was using OUTPUT_URL instead of PXE_TFTP_URL... that's why the right access of the files was not preserved.
When using PXE_TFTP_URL, everything is fine.

You can close this request.

jsmeix commented at 2017-04-13 07:08:¶

@schabrolles
many thanks for all your testing and thorough analysis!
That helps a lot to make ReaR better.
In this case we can ignore the proposed change in this pull request
but we cannot ignore your finding that using OUTPUT_URL
instead of PXE_TFTP_URL does not work for PXE boot.
If this is not yet properly documented, it should be
properly documented at least in default.conf.

@schabrolles
because I am not a PXE boot user, I would very much appreciate it
if you could check if ReaR usage for PXE boot is properly documented
and if not do a new pull request with documentation enhancements.

Again, many thanks for your valuable contributions to ReaR!

schabrolles commented at 2017-04-13 15:34:¶

@jsmeix, I will have a look to the documentation, but I've found a good example in usr/share/rear/conf/examples/PXE-booting-example-with-URL-style.conf.
One Idea could be to have this example directory directly in /etc/rear. it will help New user to easily start using ReaR.

I will also send some other pull request regarding PXE/TFTP. I need some modification to make work properly on POWER architecture which does not support PXE natively but grub (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-installation-server-setup.html).

I will open a another request to discuss about this subject with you.

[Export of Github issue for rear/rear.]

#1278 PR closed: Change default Permission on Files and Directory in tftpboot.¶