Crash Course in System Security (CSCI 1005), Winter 2025

pete > courses > Crash Course in System Security (CSCI 1005), Winter 2025 > Day 02

Day 02: Introduction to Linux

goals:

be able to traverse/inspect/modify Linux filesystem
be able to run programs from the shell
be able to look up manpages
be able to combine programs into pipelines to solve larger problems
be able to encode more complex logic into shell scripts

intro to linux (or, rather, intro to linux from the shell)

This is very much drinking from the firehose! I do not expect you to be masters and mistresses of all these tools and concepts within the next few hours. Rather, I hope to provide you with basic understanding of the common methods of interaction and a broad but shallow survey of useful programs. You will see many of these concepts repeatedly over the next few weeks and grow intimately familiar with them; some of them, not so much. Consider this a reference, helping to jog your memory when you think to yourself, ``didn’t we talk about a program that does XYZ? I wonder what it was called and how it works?’’

running programs

explicitly type name instead of point-and-double-click
command-line arguments (short and long), -h and --help
ps, man
difference between program and process

directory hierarchy

everything starts from the root (/)
delimiter: /
pwd, ls, cd, touch, rm, mkdir, rmdir, globbing
. and ..
revisit running programs and introduce $PATH, echo, and ./foo
tab completion

permissions and file types

directory, regular files, symlink, devices, /dev/null, executable, sticky bit
chown, chmod, sudo, file

stdin/stdout/stderr

echo, cat, redirection
arg conventions for - and -- prefixes
revisit /dev/null

filters

grep, awk, sed, sort, uniq, cut

pipelines

other useful tools

find, xargs, diff, tar, gzip, date, head, tail, wc, du, sleep, less, seq, stat, cron

References

Exercises

Linux kernel scavenger hunt

Download a tarball of the source code for the Linux kernel from kernel.org. The pacman program will come in handy to determine the version of the kernel you’re running and the the wget or curl programs may come in handy for downloading from the command-line (you can also download it using a browser).
Extract the contents with the command tar -xJf *filename*.
Read/skim the tar manpage to understand what you just did.
Among many other things, the Linux kernel is responsible for producing data when a given file is asked to be read. You’re used to this involving disk access, but this isn’t strictly necessary: for instance, all "files" under /proc are dynamically generated by the kernel when you request them. The file "/proc/self/maps" doesn’t exist on disk, but if you run cat /proc/self/maps, you get some meaningful information.
Your task is to find the precise lines of code within the Linux kernel that produces that information.

Scoping the problem

I mentioned yesterday that the Linux kernel has a bazillion (approx) lines of code, in which potential vulnerabilities may be lurking. Count the lines of code in the Linux kernel.

This will involve determining what qualifies as "code" (the find and file commands might come in handy) and then doing the counting.

Customize your shell prompt

The contents of the bash environment variable PS1 controls the appearance of your shell prompt. Figure out the format of the magical incantation that speaks to PS1.

You can test new values for PS1 by setting its value in the current shell: export PS1="foo bar baz" (In very simple terms, export is the command to set an environment variable—it’s actually more complicated than this, but you don’t need to worry about those details right now).

You’ll note that, if you log out and log back in again, your prompt reverts to its default format. Make your change persistent by putting your export command in the file ~/.bashrc.

If you’re super-ambitious, try setting colors: http://misc.flogisoft.com/bash/tip_colors_and_formatting

If you’re super-super-ambitious, read the bash manpage to understand all the settings customization you can perform, as well as how/when/why ~/.bashrc is evaluated as opposed to ~/.bash_profile.

Explore processes

Programs are files on disk that may be executed. When they are executed, they become running processes. (We’ll explore how a program becomes a process later on.) The ps command shows running processes.

By default, ps doesn’t show many processes. Figure out why. Figure out how to show all processes currently running on the machine.

Memory leaks are bad. Generate a list of the top 5 memory hogs currently running.

Like intrepid American explorers, now you get to kill the stuff you’ve explored. The kill command terminates a process (again, it’s more complicated, but that’s all you need to know for now). Figure out how it works. Start up a program and kill it.

If you’re like me, you will not infrequently happen upon a situation in which you want to kill a bunch of processes at once. Write a shell pipeline that finds all processes containing the string "bash" and kills them. You will find the cut and xargs commands handy.

Advanced shell scripting

Like compiled programs such as ls, grep, and find, shell scripts can accept command-line arguments. Modify the shell script you wrote above to accept the filter string as a command-line argument. (You will find the Advanced Bash-Scripting Guide useful here—pay particular attention to not just the material on command-line arguments, but also that on quoting and interpolation.)

Further Arch Linux resources

You may come across some software for which Arch Linux does not provide a binary package (ie, packages containing compiled machine code). In this case, Arch often instead provides instructions on how to build a binary package of your very own; learn more about the Arch User Repository.

The Arch Linux Wiki is an immensely valuable repository of knowledge.

Among other things, it contains a list of common applications. Explore this list. Install software that piques your interest. Play around. Have fun.