This section discusses security: avoiding downtime, avoiding revealing sensitive information, avoiding unwanted modifications to the data; either through accident or malice. A good introduction to secure programming can be found in Secure Programming for Linux and Unix HOWTO. For yaird, security is not very complicated: although it runs with root privileges, the program is not setuid, and all external input comes from files or programs installed by the admnistrator, so our main focus is on avoiding downtime caused by ignored error codes. A full blown risk assessment would be overkill, so we'll just use the HOWTO as a checklist to verify that the basic precautions are in place. Group Mitigation Status Bad input Verify command line Yes. Bad input Verify and clean up environment Complete environment is reset at start of program. Bad input Avoid assumptions about file descriptors Handled by perl. Bad input Verify file names Perl taint check shows filenames are verified for absence of odd characters before passing to subprocesses. TODO: examine UTF-8 impact. Bad input Verify file content File contents in sysfs verified. Fstab entries properly quoted. TODO: check for spaces in names of LVM volume or of modules; could end up in generated /sbin/init. Bad input Verify locale settings All locale related environment variables are wiped at program startup. Bad input Verify character encoding All IO is byte oriented. Bad input Buffer overflow In perl? Program structure Separate data and control Under this heading, the HOWTO discusses the dangers of auto-executing macros in data files. The closest thing we have to a data file are the templates that tune the image to the distribution. We use a templating language that does not allow code embedding, and the image generation module does not make it possible for template output to end up outside of the image. Conclusion: broken templates can produce a broken image, but cannot affect the running system. Program structure Minimize privileges The user is supposed to bring his own root privileges to the party, not much to be done here. A related issue is the minimizing of privileges in the system that is started with the generated image. This would include starting SELinux at the earliest possible moment. At least in Fedora, that earliest possible moment is in rc.sysinit, well past the moment where the initial boot image hands over control to the newly mount root file system. No yaird support needed. Program structure Safe defaults Configuration only specifies sources of information, like /etc/hotplug, not much can go wrong here. Program structure Safe Initialisation The location of the main configuration file is configured as an absolute path into the application. Program structure Fail safe Planning and writing the image is separated; writing only starts after planning is succesfully completed. Todo: consider backout on write failure. Program structure Avoid race conditions Temporary files and directories are created with the File::Temp module, which is resistant to name guessing attacks. The completed image is installed with rename rather than link; if an existing file is overwritten, this guarantees there's no race where the old image has been deleted bu the new one is not yet in place. (Note that there is no option in place yet which allows overwriting of existing files.) To do: examine File::Temp safe_level=HIGH. Underlying resources Handle meta characters Protection against terminal escape sequences in output is not yet in place. Underlying resources Check system call results Yes. Language specific Verify perl behaviour with taint. Yes. Language specific Avoid perl open magic with 3rd argument. Yes.