codeblog code is freedom — patching my itch

February 28, 2010

egosurfing with git

Filed under: Blogging,Debian,Ubuntu,Ubuntu-Server — kees @ 12:19 pm

I’m never sure when my commits to Linux actually make it into an official release. Luckily, since releases are tagged, I can use “git tag --contains COMMIT” to find them. So, in a stunning display of inefficiency, here’s what I use to find my commits:

git log --author='Kees Cook' --pretty=oneline | \
while read commit name; do \
    echo $(git tag --contains $commit | head -n1): "$name"; \
done

Which lets me know where my code is with respect to releases:

v2.6.33: x86, mm: Report state of NX protections during boot
v2.6.33: sysctl: require CAP_SYS_RAWIO to set mmap_min_addr
v2.6.32: proc: fix reported unit for RLIMIT_CPU
v2.6.31: modules: sysctl to block module loading
...

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

February 25, 2010

fun with process scheduling

Filed under: Debian,Ubuntu,Ubuntu-Server — kees @ 11:04 am

In an attempt to force an exec to totally stall so I could attach gdb to a process that does a setuid transition without freaking it out (i.e. can’t launch “sudo gdb …”), I briefly played with process priority, scheduling, and CPU affinity (pinning a process to a CPU).

So far, the best attempt at stalling the process was to set CPU affinity, set its scheduling policy (IDLE), drop the priority value fully (19), and then run a CPU hog with the same CPU affinity with a very high priority (-20).

Staller: sudo schedtool -a 0 -N -n -20 -e /tmp/spin-cpu
Stallee: schedtool -a 0 -D -n 19 -e /usr/bin/sudo -s

The hope was to then run “sudo gdb /usr/bin/sudo $(pidof sudo)“, but it seems that this still isn’t enough to make the exec of sudo totally stall while the “spin-cpu” process is running — it certainly executes more slowly, but I want it to stop.

I have this feeling like I’m missing something obvious about how to accomplish this gdb session sanely. I wonder if I can get gdb to switch targets across a child exec, i.e. run gdb as root on a program that fully drops privs, but then execs sudo. Guess it’s time to go read the gdb manual some more…

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

February 18, 2010

data mining for NX bit

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

9% of Ubuntu systems that were used to report bugs that included their /proc/cpuinfo file need to fix their BIOS settings to gain the NX bit.

Check for yourself. (Run it with --verbose for useful details.)

Out of 7511 Ubuntu bugs Brian Murray collected for me that included /proc/cpuinfo files, there were 7270 unique contents (which surprised me — I was expecting this to be much lower).

  • 5 (0.07%) were non-x86.
  • 1 (0.02%) had corrupted contents (likely due to a search/replace in apport gone awry).
  • 5670 (77.99%) had NX (this also surprised me — I was not expecting it to be so high).
  • 337 (4.64%) lacked PAE, and so cannot have NX (I didn’t expect this to be so low; Ubuntu bug reporters must have relatively recent hardware overall).
  • 595 (8.18%) had PAE and correctly lacked NX (I didn’t expect this to be so high — PAE without NX is a bit more common than I’d hoped; hopefully these systems are running 32bit kernels to at least get the partial NX emulation).
  • 662 (9.1%) had PAE but incorrectly lacked NX.

It’s this last group of systems I’m hoping to get fixed through education.

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

February 9, 2010

easy example of filesystem capabilities

Filed under: Blogging,Debian,Networking,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

Instead of using setuid programs, the goal for the future is to use fine-grained capabilities. For example, here is /bin/ping:

$ ls -la /bin/ping
-rwsr-xr-x 1 root root 35680 2009-11-05 00:41 /bin/ping
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms
…
$ sudo setcap CAP_NET_RAW=ep /bin/ping
$ getcap /bin/ping
/bin/ping = cap_net_raw+ep
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms
…
$ dmesg | tail -n1
[212275.772124] warning: `/bin/ping’ has both setuid-root and effective capabilities. Therefore not raising all capabilities.

The best part is that the kernel will choose the set of least privileges when both setuid and capabilities exist. Easy way to transition!

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

February 8, 2010

rng-tools with TPM

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 7:32 pm

In Ubuntu, I uploaded an rng-tools that supports the RNG in TPM devices (my patch is waiting in Debian). This hardware is available on a bunch of systems, including several Thinkpads and the Intel Q35, Q45 and newer main boards.

While most TPM RNGs aren’t really heavy-duty hardware RNGs, they are at least a mild source of randomness. I’ll be using an entropy key eventually, but for now, the TPM can supplement my collected entropy.

/etc/default/rng-tools:

HRNGDEVICE=/dev/null
RNGDOPTIONS=”–hrng=tpm –fill-watermark=90% –feed-interval=1″

After it’s been running a bit:

Feb 8 19:10:51 linux rngd[13143]: stats: bits received from HRNG source: 6180064
Feb 8 19:10:51 linux rngd[13143]: stats: bits sent to kernel pool: 6166144
Feb 8 19:10:51 linux rngd[13143]: stats: entropy added to kernel pool: 4624608
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2 successes: 309
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2 failures: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Poker: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Runs: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Long run: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Feb 8 19:10:51 linux rngd[13143]: stats: HRNG source speed: (min=5.207; avg=6.145; max=6.200)Kibits/s
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS tests speed: (min=66.925; avg=75.789; max=112.861)Mibits/s
Feb 8 19:10:51 linux rngd[13143]: stats: Lowest ready-buffers level: 0
Feb 8 19:10:51 linux rngd[13143]: stats: Entropy starvations: 308
Feb 8 19:10:51 linux rngd[13143]: stats: Time spent starving for entropy: (min=3150263; avg=3178447.994; max=3750848)us

And now the kernel entropy pool is high:

$ echo $(cat /proc/sys/kernel/random/entropy_avail)/$(cat /proc/sys/kernel/random/poolsize)
3968/4096

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

Powered by WordPress