/dev/null and /dev/urandom not available in chroot

decuser

decuser

So, I have an application (fossil) that is started up as root by inetd. It chroots, drops privileges and so on, but the chroot needs access to /dev/null and /dev/urandom. I can start the app with --nojail, which skips the chroot and it will work fine, but it's designed to run in a chrooted environment that has access to these two special devices. How can I manually create them in the chroot? I saw linux instructions using mknod, but unlike linux the freebsd system doesn't appear to have standard major minor numbers for these:


Code: 
crw-rw-rw-  1 root  wheel  0x2a Feb  8 21:44 /dev/null
crw-r--r--  1 root  wheel   0x4 Feb  8 21:41 /dev/random
lrwxr-xr-x  1 root  wheel     6 Feb  8 21:41 /dev/urandom -> random

Help :)
 
FreeBSD's ls(1) just displays major/minor as a single hex number, the higher byte is the major and the lower the minor number (so, for your /dev/null, it's major 0, minor 0x2a). You can create it with mknod null c 0 0x2a.

BUT: This will be useless. See mknod(8)
As of FreeBSD 6.0 device nodes may be created in regular file systems but such nodes cannot be used to access devices.
Click to expand...

Device nodes on FreeBSD only work inside devfs(8).

On FreeBSD, you're supposed to use a jail(8) with a devfs mounted inside and a devfs ruleset making only the devices you want available.

Side note, looking at some info about fossil I found (more or less only used for sqlite, features for rewriting history removed for dogmatic reasons, not scaling to huge projects, ...), you might want to reconsider your choice anways...
 
mount devfs with specific rules
look at /etc/rc.subr for devfs_domount()
and/or install dns/bind at look at its startup script (it just does that)
Code: 
#ls -l /var/named/dev/
total 0
crw-rw-rw-  1 root  wheel  0xe Feb  9 06:57 null
crw-r--r--  1 root  wheel  0x5 Jan 21 09:49 random
 
Zirias said:
FreeBSD's ls(1) just displays major/minor as a single hex number, the higher byte is the major and the lower the minor number (so, for your /dev/null, it's major 0, minor 0x2a). You can create it with mknod null c 0 0x2a.

BUT: This will be useless. See mknod(8)


Device nodes on FreeBSD only work inside devfs(8).

On FreeBSD, you're supposed to use a jail(8) with a devfs mounted inside and a devfs ruleset making only the devices you want available.

Side note, looking at some info about fossil I found (more or less only used for sqlite, features for rewriting history removed for dogmatic reasons, not scaling to huge projects, ...), you might want to reconsider your choice anways...
Click to expand...
Thanks. That helps. I'm off to reading up on devfs and rulesets. On the side note. I appreciate the tip, but my personal projects aren't huge and 20 minutes with fossil showed me some amazing possibilities for my personal environment that I have been missing for two decades with git and scm-manager. I know a lot of folks imagine themselves doing massively parallel, hyper-secure programming, but the reality is often much more mundane. I have what I like to think are some fairly large repos (upwards of 3 gigs), fossil chewed 'em up and spit out in about a little less than a minute with no errors. I have zfs snapshots (thanks bsd) and regular backups, so I'm comfortable in the playground - there's only so much damage I can do in the shortterm anyway:). As for sqlite (that's a pretty strong recommendation) just my favorite database ever! But seriously, thanks for cautioning me. I wouldn't try this at home without my zfs safetynet and a fantastic dircmp setup :).
 
decuser I've done upgrade inside a BE and one of the steps is doing the following after a chroot:
mount -t devfs devfs /dev

If the startup is via a script you may be able to modify it to add this.
 
decuser don't get me wrong, I didn't expect using fossil to be "dagerous" or something like that. My concern (apart from scalability issues that really are only relevant for huge projects) is that it seems to enforce some dogmatic opinions on the user, therefore missing some nice features. I didn't find anything it can do that git can't, but maybe I overlooked something...

As for the original device node issue, following covacat's idea, you can of course mount it manually and let the software use its chroot. I'd still prefer a full-featured jail, though, but that's just my preference :)
 
Zirias said:
decuser don't get me wrong, I didn't expect using fossil to be "dagerous" or something like that. My concern (apart from scalability issues that really are only relevant for huge projects) is that it seems to enforce some dogmatic opinions on the user, therefore missing some nice features. I didn't find anything it can do that git can't, but maybe I overlooked something...
Click to expand...

The wiki is built in, which I like. I also like the lightweight nature of checkouts - one local clone, many sandboxes, branching as needed, not needing much planning, a few little things. Other than the wiki, most of it CAN be done in git, but requires extra work. I'm still a newb on the fossil front (git for decades) so I'm not looking to evangelize it, but after having it installed for all of a day, I really like how it works...

Zirias said:
As for the original device node issue, following covacat's idea, you can of course mount it manually and let the software use its chroot. I'd still prefer a full-featured jail, though, but that's just my preference :)
Click to expand...
I'm not that jail savvy, I suppose this could me my next learning project... getting a service running in a jail - sounds constrained enough to keep me busy without my abandoning hope of getting it working!
 
Zirias , oh and even though we're way off topic, the fossil website (webpages, chat, wiki, forums, everything but the downloads section) is a simple instance of fossil. I found the software when I was working on a completely unrelated PDP8 project:


Which is similarly self-hosted as part of it's repo.

This prolly doesn't scale for very large projects, but I was wanting a way to store more accessible documentation alongside my repos, and this fit the bill nicely.
 
decuser said:
So, I have an application (fossil) that is started up as root by inetd.
Click to expand...
Why is it running as root? The package is obviously not supposed to that.

decuser said:
It chroots, drops privileges and so on
Click to expand...
Meh.

decuser said:
I can start the app with --nojail, which skips the chroot and it will work fine, but it's designed to run in a chrooted environment that has access to these two special devices.
Click to expand...
Also meh. Chroot "jail" can't offer better protection than running a daemon under the user with minimal priveleges in the first place and it easily can be worse.
 
shkhln said:
Why is it running as root? The package is obviously not supposed to that.


Meh.


Also meh. Chroot "jail" can't offer better protection than running a daemon under the user with minimal priveleges in the first place and it easily can be worse.
Click to expand...
Meh. It's running at home behind a firewall. But, I'd love to learn more about how to run it "under the user with minimal privileges." I just followed the directions on their website for getting it running. So, where's some good documentation on the subject.
 
Maybe, if you were talking to a full time sysadmin, what you're saying might make sense. I'm just a decades long user of a set of home servers. Still, I don't want to do stupid, if I can help it, so if you can say something actionable or point me at some documentation, great. I'm all ears. I know enough to recognize that running as root is bad, but not enough to know how to fix it. Any help is appreciated, but kibbitzing? I'm too old and ornery.
 
shkhln said:
Meh.
Click to expand...
I like daemons dropping privileges, I'm building this feature into my own daemons as well. What's wrong with that? It doesn't prevent you from starting it unprivileged in the first place...

One classic/historic reason for this feature is the ability to listen on a port <1024.
 
Zirias said:
I like daemons dropping privileges, I'm building this feature into my own daemons as well. What's wrong with that?
Click to expand...
Wrong is not quite an appropriate word. Fossil seems to be calling setgid/setuid/chroot early enough this not a huge concern, but in general if reading, say, malformed config at startup causes a crash, being root at that moment is not exactly ideal. So, fewer apps starting as root means we have to trust less code. I'm certainly not going to study startup code for every application out there.
 
You must log in or register to reply here.
Back
Top