I'm thinking out loud here, so I may easily be confused, but... What if we replaced the chroot() system call by an overlay file system, mounted over some subtree? The advantage is that that file system could be mounted read-only, nosuid, nodev, even noexec.
>>>>> "Steven" == Steven M Bellovin <smb <at> cs.columbia.edu> writes:
Steven> I'm thinking out loud here, so I may easily be confused,
Steven> but...
Steven> What if we replaced the chroot() system call by an overlay
Steven> file system, mounted over some subtree? The advantage is
Steven> that that file system could be mounted read-only, nosuid,
Steven> nodev, even noexec.
So,
chroot("/my/foo");
becomes the same as something:
mount -o ro,nosuid,noexec,nodev -t union /something /my/foo
chroot /my/foo
(where /something might even be /)
I'm a bit ignorant of union file systems wrt: "nodev". If the lower file
system has "dev" enabled, and the upper file system has "nodev", does
that mean that the /dev entries show through, but that when you try to
create new ones, they don't work?
--
--
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr <at> xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
(Continue reading)On Tue, 01 Nov 2005, Steven M. Bellovin wrote: > I'm thinking out loud here, so I may easily be confused, but... > > What if we replaced the chroot() system call by an overlay file > system, mounted over some subtree? The advantage is that that file > system could be mounted read-only, nosuid, nodev, even noexec. One problem that comes to mind - what if you want multiple processes chroot()ed into the same space? It seems that you would end up with stacked mounts, and the older ones can't be unmounted via the exising stackable filesystem model, until the newer ones are released. Additionally, is it possible you might want 'noexec' etc, to apply to only some of the processes in that chrooted area? I don't that works with the filesystem thought. -- -- David Maxwell, david <at> vex.net|david <at> maxwell.net --> (About an Amiga rendering landscapes) It's not thinking, it's being artistic! - Jamie Woods
On Wed, Nov 02, 2005 at 10:45:43AM -0500, mcr wrote:
>
> So,
> chroot("/my/foo");
>
> becomes the same as something:
> mount -o ro,nosuid,noexec,nodev -t union /something /my/foo
> chroot /my/foo
>
> (where /something might even be /)
>
At which point I would be worried about a privilege escalation leading
to my password database being snatched for offline cracking. The nice
thing about chroot is that you don't have the encrypted passwords
laying about.
--
--
Brett Lymn
On Tue, Nov 01, 2005 at 07:49:59PM -0500, Steven M. Bellovin wrote: > I'm thinking out loud here, so I may easily be confused, but... > > What if we replaced the chroot() system call by an overlay file > system, mounted over some subtree? The advantage is that that file > system could be mounted read-only, nosuid, nodev, even noexec. Two points, stated somewhat facetiously for dramatic effect (or something): * This and some of the followup sounds a lot like you want (or might soon afterwards want) per-process mounts. While I can think of a number of other potentially useful things to do with such an animal, "if you want plan9 you know where to find it"* Systrace is probably a far more effective way to express the permissions you want your overlay to enforce than writing a new filesystem each time - and if it's not, perhaps that's where improvements should go? -- Dan.
In message <20051103021022.GX24589 <at> bcd.geek.com.au>, Daniel Carosone writes: > > >On Tue, Nov 01, 2005 at 07:49:59PM -0500, Steven M. Bellovin wrote: >> I'm thinking out loud here, so I may easily be confused, but... >>=20 >> What if we replaced the chroot() system call by an overlay file >> system, mounted over some subtree? The advantage is that that file >> system could be mounted read-only, nosuid, nodev, even noexec. > >Two points, stated somewhat facetiously for dramatic effect (or >something): > > * This and some of the followup sounds a lot like you want (or might > soon afterwards want) per-process mounts. While I can think of a > number of other potentially useful things to do with such an > animal, "if you want plan9 you know where to find it"(Continue reading)
>>>>> "Brett" == Brett Lymn <blymn <at> baesystems.com.au> writes:
>> So, chroot("/my/foo");
>>
>> becomes the same as something: mount -o ro,nosuid,noexec,nodev -t
>> union /something /my/foo chroot /my/foo
>>
>> (where /something might even be /)
>>
Brett> At which point I would be worried about a privilege
Brett> escalation leading to my password database being snatched for
Brett> offline cracking. The nice thing about chroot is that you
Brett> don't have the encrypted passwords laying about.
right, there are different reasons for chroot().
Sometimes, you *do* want to be able to read stuff. Maybe even
passwords. (think pop daemon...) Sometimes you do not.
--
--
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr <at> xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
On Tue, Nov 01, 2005 at 07:49:59PM -0500, Steven M. Bellovin wrote: > I'm thinking out loud here, so I may easily be confused, but... > > What if we replaced the chroot() system call by an overlay file > system, mounted over some subtree? The advantage is that that file > system could be mounted read-only, nosuid, nodev, even noexec. The problem I see with nodev is that that means we don't have /dev/null. My understanding is that chroot environments often need a _few_ devices, and with nodev they get none. Also, overlay file systems add vnode overhead. If we need it, it's good. But I'm not sure if I feel comfortable with us making one for each chroot environment. I'd say that either systrace or something like Solaris's capabilities would be a good route to go. If we make making device nodes a "capability" and the chroot processes don't have it, no new devices.
In article <20051102004959.D95A13BFCE0 <at> berkshire.machshav.com>, "Steven M. Bellovin" <smb <at> cs.columbia.edu> writes: > What if we replaced the chroot() system call by an overlay file > system, mounted over some subtree? The advantage is that that file > system could be mounted read-only, nosuid, nodev, even noexec. You can't use "nodev": tron <at> colwyn:~>ls -l /var/chroot/named/dev total 0 crw-rw-rw- 1 root wheel 2, 2 Dec 27 2003 null cr--r--r-- 1 root wheel 46, 0 Mar 12 2002 random And without "nodev" somebody with root privileges can still escape or at least cause damage. Maybe we need a "nomakedev" option? Kind regards -- -- Matthias Scheler http://scheler.de/~matthias/
On Fri, 4 Nov 2005, Matthias Scheler wrote: > And without "nodev" somebody with root privileges can still escape > or at least cause damage. Maybe we need a "nomakedev" option? While we're talking about this, the first thing that occurred to me when this thread started was that Steve seems to have the exact opposite problem that I do. (I'm not sure why.) I used always to mount /var nodev,nosuid, just like /tmp. (I reckon if there's a world writable directory in there, nodev,nosuid can't hurt.) But I can't do that any more because of stuff like ntp, which is chrooted into /var/chroot, and needs a device. cjs -- -- Curt Sampson <cjs <at> cynic.net> +81 90 7737 2974 Make up enjoying your city life...produced by BIC CAMERA
RSS Feed2 | |
|---|---|
6 | |
3 | |
6 | |
16 | |
6 | |
28 | |
6 | |
4 | |
2 | |
20 | |
12 | |
4 | |
4 | |
10 | |
16 | |
2 | |
2 | |
1 | |
7 | |
1 | |
3 | |
1 | |
16 | |
2 | |
3 | |
3 | |
2 | |
13 | |
9 | |
10 | |
3 | |
4 | |
1 | |
9 | |
1 | |
11 | |
7 | |
10 | |
2 | |
1 | |
1 | |
12 | |
11 | |
8 | |
7 | |
38 | |
10 | |
19 | |
3 | |
16 | |
11 | |
2 | |
17 | |
18 | |
14 | |
16 | |
6 | |
7 | |
7 | |
37 | |
27 | |
12 | |
12 | |
3 | |
11 | |
12 | |
50 | |
7 | |
2 | |
12 | |
73 | |
32 | |
55 | |
61 | |
28 | |
37 | |
71 | |
18 | |
8 | |
6 | |
22 | |
97 | |
59 | |
111 | |
45 | |
45 | |
41 | |
54 | |
113 | |
107 | |
46 | |
27 | |
87 | |
163 | |
21 | |
30 | |
9 | |
73 | |
10 | |
4 | |
8 | |
62 | |
85 | |
35 | |
28 | |
15 | |
12 | |
21 | |
23 | |
246 | |
27 | |
16 | |
58 | |
22 | |
20 | |
36 | |
3 | |
31 | |
27 | |
56 | |
179 | |
67 | |
87 | |
92 | |
143 | |
87 | |
75 | |
1 |
