-
Notifications
You must be signed in to change notification settings - Fork 13
/
DEVELOPERS
85 lines (73 loc) · 4.39 KB
/
DEVELOPERS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
Project Bitscout
Author: Vitaly Kamluk // bitscout[at]kaspersky.com
This file briefly describes the structure of the project for developers.
Base system
Current base system is Ubuntu 22.04 LTS.
Virtualization
Bitscout relies on LXC 1.0 for virtualization. One option was to use full VM, but
given that we are runing from live media, it had to be something lightweight
and optimal. LXC perfectly works here, because kernel becomes shared between the
container and the host. Also, kernel mechanisms for IPC, such as file locking
and pipes can be used for IPC between the host and the guest. We used
unprivileged container that runs as user. However, we need to provide rootfs to
such container and as far as we used the same source from squashfs, we had to
remap uid/gid for some otherwise inaccessible files. So far the script that
starts the container does this job and remaps uid/gid to subuid/subgid of the
target user for the whole root filesystem. This lets us avoid data duplication
in memory.
Optimisation
We aimed to make the system optimal in size. You may find extensive usage of
overlayfs, compressed memory block device (zram) and more tuning to save space.
Both host and guest system run from the same source image, but each of the
system can be independently extended or modified.
Extension
The system is designed to be extended in memory. Both host and guest users can
install additional packages in RAM.
Customisation
The best way to customize your own build of Bitscout is to create additional
script in scripts directory. Unless you suggest a bugfix, please stick to
extension of the code, rather than patching existing pieces. And you are very
welcome to submit you suggested fixes and improvements. We know there is a lot
to be done to improve security, stability and usability of the project.
When you make a new task to modify rootfs or other things, please write in the
way that doesn't apply changes twice if the same script is executed again.
Current scripts follow this idea, this allows to make tiny changes and rerun the
subscripts without risk to break the final system. I.e. you can make some change to
the way how container is created (./scripts/chroot_create_container.sh) and then
manually run ISO rebuild (./scripts/image_build.sh). That shall generate you the
new ISO file with your changes applied without the need to run all other scripts.
Structure and description of the files:
automake.sh - this is core script that runs others. Feel free to run it whole or
part of it (i.e. to avoid recurring base system download).
scripts/ - this is directory with scripts to do main tasks. Some are prefixed
according to current stage of execution:
welcome.sh - the initial global configuration script and welcome message.
chroot_* - scripts to install, configure and change root filesystem
image_* - scripts to pack rootfs and generate ISO file
export_generate.sh - prepare configs for other systems (VPN server, expert)
initrd_* - these can pack/unpack initrd image. Used for initrd patches.
chroot_enter.sh/chroot_leave.sh - these scripts can be used if you would like
to run shell in chrooted environment. For the sake of automation it
relies on screen tool that runs as root. To use this, run the first
script and then "sudo screen -r" to join the screen session. To
leave it simply run scripts/chroot_leave.sh from a separate shell.
And, yes, if you know a better way to do that, please suggest!
functions - this file is included by others, provides most common settings and
global utility functions, i.e. running commands in chrooted screen
session.
Running scripts
Currently all scripts have to be called from the root directory of the project, i.e.
$ ./scripts/image_build.sh
How to contribute
We'd love to have you contribute! Our goal is to have a builder that can build
the smallest Live OS useful for forensics. It would be nice to further reduce
the size of the ISO file to te best possible minimum. If you are into it, look
into image_prebuild_cleanup.sh. Perhaps you could bring it to a new level!
One thing to consider: we need to keep essential features, which include:
1. Disk controllers' and RAID modules
2. Network devices
3. LXC support
4. Filesystems support
If you want to try your ideas, make sure you read these articles first:
https://wiki.debian.org/ReduceDebian
https://wiki.ubuntu.com/ReducingDiskFootprint