Re: A TrustedBSD voluntary sandbox policy.
On Thu, 8 Nov 2007, Andrea Campi wrote: On Wed, Nov 07, 2007 at 10:20:28PM -0500, [EMAIL PROTECTED] wrote: I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. ... Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. Can't comment on the implementation or wider issues, but if you pursue this, please have a look at how MacOS Leopard does it (Seatbelt). Would be nice to converge on both syntax (a Schema dialect) and tools names / command line args--or if converging is not possible, at least know where and why and make a conscious decision. FYI, Seatbelt is based on the Mac OS X port of the TrustedBSD MAC Framework, which while it has some significant changes (some now present in the 8-CURRENT branch of FreeBSD), may well be a good starting point. Last I checked, the source for Seatbelt wasn't yet available, but there was hope it would be available in the near future. A port of the policy to FreeBSD sounds like it would be very interesting to do, and might provide a nice starting point rather than having to write up a policy from scratch. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A TrustedBSD voluntary sandbox policy.
On Nov 8, 2007 9:23 AM, Pawel Jakub Dawidek [EMAIL PROTECTED] wrote: First problem is that it is hard to operate on file paths. MAC passes a locked vnode to you and you cannot go from there to a file name easly. You could do it by comparsion: call VOP_GETATTR(9) on the given vnode, do the same for /etc/passwd and others and compare their inodes and file system ids. Performance hit may be significant for complex policies. You can register yourself for process_exit, process_fork and process_exec in-kernel events and do your cleanups from your event handler. Take a look at EVENTHANDLER(9). -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! Couldn't you use stat() syscall on the paths from the userland utility that parses the rules, collect the mount point or mount id and the inode from the stat struct, then have the MAC policy module match that data with the file id and mount id available from the vnode? -- Christopher Davis ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A TrustedBSD voluntary sandbox policy.
On Wed, Nov 07, 2007 at 10:20:28PM -0500, [EMAIL PROTECTED] wrote: I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. ... Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. Can't comment on the implementation or wider issues, but if you pursue this, please have a look at how MacOS Leopard does it (Seatbelt). Would be nice to converge on both syntax (a Schema dialect) and tools names / command line args--or if converging is not possible, at least know where and why and make a conscious decision. Bye, Andrea -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A TrustedBSD voluntary sandbox policy.
On Wed, Nov 07, 2007 at 10:20:28PM -0500, [EMAIL PROTECTED] wrote: I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. I'm aiming for a much simpler implementation, however. No interaction. No privilege elevation (only restriction). No system call rewriting, only access control. The interface will look something like this: (cat EOF deny all allow file_open /etc/passwd allow file_open /dev/tty allow sock_connect 127.0.0.1 80 allow sock_connect 208.77.188.166 80 rlimit core 0 rlimit cpu 20 rlimit nofile 10 EOF ) | sandbox /bin/ls -alF /bin Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. The implementation appears to be simple, as far as I'm aware. I'm sure there will be thorns and problems - that's what I'm here to find out. The 'sandbox' process compiles the policy text into a binary structure in userland, loads the binary structure into the kernel module via a system call implemented with mac_syscall(), sets various rlimits and then runs /bin/ls with execve(). When the process exits, the memory for the binary structure is freed. I would like, at this stage, to know if the above model is seriously incompatible with the way the MAC framework works, it's not entirely clear either way having read other policies such as mac_biba, mac_stub etc. For example - how to know when a process has exited? Policy for an executed process would be kept in a small hash table, indexed by process id. The policy will be enabled when the process sucessfully calls execve() for the first time and will be destroyed when the process exits. If we're not notified when a process has exited, we can't remove policy from the table. Also, what should be done when a process decides to fork() or execve()? It'd be rather unfortunate if the process could break out of the sandbox just by executing another process but blocking all attempts to fork() or execve() would make classes of programs unusable. First problem is that it is hard to operate on file paths. MAC passes a locked vnode to you and you cannot go from there to a file name easly. You could do it by comparsion: call VOP_GETATTR(9) on the given vnode, do the same for /etc/passwd and others and compare their inodes and file system ids. Performance hit may be significant for complex policies. You can register yourself for process_exit, process_fork and process_exec in-kernel events and do your cleanups from your event handler. Take a look at EVENTHANDLER(9). -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpnSAKoJorcw.pgp Description: PGP signature
A TrustedBSD voluntary sandbox policy.
I'm considering developing a policy/module for TrustedBSD loosely based on the systrace concept - A process loads a policy and then executes another program in a sandbox with fine grained control over what that program can do. I'm aiming for a much simpler implementation, however. No interaction. No privilege elevation (only restriction). No system call rewriting, only access control. The interface will look something like this: (cat EOF deny all allow file_open /etc/passwd allow file_open /dev/tty allow sock_connect 127.0.0.1 80 allow sock_connect 208.77.188.166 80 rlimit core 0 rlimit cpu 20 rlimit nofile 10 EOF ) | sandbox /bin/ls -alF /bin Please note that the 'policy' given on the command line is purely for the sake of example, no syntax or semantics have been decided upon. The implementation appears to be simple, as far as I'm aware. I'm sure there will be thorns and problems - that's what I'm here to find out. The 'sandbox' process compiles the policy text into a binary structure in userland, loads the binary structure into the kernel module via a system call implemented with mac_syscall(), sets various rlimits and then runs /bin/ls with execve(). When the process exits, the memory for the binary structure is freed. I would like, at this stage, to know if the above model is seriously incompatible with the way the MAC framework works, it's not entirely clear either way having read other policies such as mac_biba, mac_stub etc. For example - how to know when a process has exited? Policy for an executed process would be kept in a small hash table, indexed by process id. The policy will be enabled when the process sucessfully calls execve() for the first time and will be destroyed when the process exits. If we're not notified when a process has exited, we can't remove policy from the table. Also, what should be done when a process decides to fork() or execve()? It'd be rather unfortunate if the process could break out of the sandbox just by executing another process but blocking all attempts to fork() or execve() would make classes of programs unusable. Comments, flames, etc, appreciated. (cc'd to trustedbsd-discuss@ regardless of whether or not anybody actually reads it). -- dc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) :-) On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: In article [EMAIL PROTECTED], Sue Blake [EMAIL PROTECTED] wrote: : Could someone tell me what is a sandbox, what does it do, how does it : work, how do I use it, or where is it documented? : named(8) and security(8) seem to assume one already knows. It's a generic term. It refers to a restricted environment in which something is to be done. Exactly how a sandbox is implemented depends on the specific application. Without having read the references in the files you mentioned, here is my own take on sandbox. In some firewall books I have read, sandbox is used to refer to a machine connected to the net in a "protected" way. Basically, all packets to and from that machine go through a firewall. The machine, though inside the firewall, is isolated from the rest of the internal network. The sandbox can then be used to provide services in a more or less secure way. It cannot threat the internal network, because it can reach it even if breached, and it is not as exposed as it would be outside the firewall. If *think* this definition was given in the book by the TIS people, but, alas, I haven't read about firewalls in two years, and my firewall books are 12 thousand km away. And notice, too, that I'm *not* refering to the hacker's trap, whose name I can't recall right now. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Is it true that you're a millionaire's son who never worked a day in your life?" "Yeah, I guess so." "Lemme tell you, son, you ain't missed a thing." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
A sandbox is a security term. It can mean two things: * A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. The process is said to be able to "play" inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security. The walls might be a userid, for example. This is the definition used in the security and named man pages. Take the 'ntalk' service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid tty. The tty user is a sandbox desiegned to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user id. * A process which is placed inside a simulation of the machine. This is more hard-core. Basically it means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chroot'd (i.e. "/" for that process is this directory, not the real "/" of the system). Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. The process may believe it is able to write to those files, but only the process sees the effects -- other processes in the system do not, necessarily. An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is unlike Windows where a process can easily overwrite the address space of any other, leading to a crash. A UNIX process is owned by a patricular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data. -Matt Matthew Dillon [EMAIL PROTECTED] :Hi clever people : :Nobody seems to be confident about the answer to my post to -questions. :Below is the only public answer. It is typical of many private answers :I received from otherwise knowledgeable people willing to make a :partial educated guess but not willing to expose their ignorance :publicly. They're all keen to know whatever I can find out :-) : :On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: : In article [EMAIL PROTECTED], : Sue Blake [EMAIL PROTECTED] wrote: : : Could someone tell me what is a sandbox, what does it do, how does it : : work, how do I use it, or where is it documented? : : named(8) and security(8) seem to assume one already knows. : : It's a generic term. It refers to a restricted environment in : which something is to be done. Exactly how a sandbox is : implemented depends on the specific application. : :As you see it is far from the complete 4-5 part answer I need. The :problem that I see is that our named.conf refers to this sandbox thing, :implies that it is actually the default method for BIND in FreeBSD (I :don't think it is though), and directs the user to man pages which :don't provide the necessary info to be able to confidently :(un)implement it. : :If nobody understands how this sandbox thing works, we should change :the named.conf that we supply. If somebody does, then they or someone :who they teach (me if really necessary) needs to document it so that :anyone seriously interested can figure it out on thier own (or at least :accept the defaults with confidence), and then change at least the :named.conf to point to that info. It sounds like a good idea, worth :giving people the resources to use it. : :(Email cc would be appreciated) : :-- : :Regards, :-*Sue*- : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) The usual use of the term "sandbox" means "restricted environment". A chroot(3) can be used to build this, and jail(3) is a stronger version, although this is not a usual use for the term. The term is popular in Java where it it implies that the (possibly hostile) applet _cannot_ do anything dangerous, because the environment it runs in has no API that allows this (like the applet cannot open arb files). The term "sandbox" in inetd.conf refers to a "su - safe_user; chroot safe_dir; app" environment (I think) so that app cannot do any damage even if compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
On Sun, Jul 25, 1999 at 11:36:49AM -0700, Matthew Dillon [EMAIL PROTECTED] wrote: A sandbox is a security term. It can mean two things: [...] UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is Can not. Silly typo ;) BTW, I have running bind running chroot()'ed in /var/named (where OpenBSD puts it). Can we now also put /var/named and all subdirs needed into FreeBSD? We can also add '-t /var/named' flag into commented out rc.conf startup for bind. I could supply more info to someone who can commit this into the tree... % tail /var/named/var/log/named-noise.log 25-Jul-1999 04:11:16.730 security: info: chrooted to /var/named 25-Jul-1999 04:11:16.871 security: info: group = bind 25-Jul-1999 04:11:16.872 security: info: user = bind % ps ax | grep named 113 ?? Is 0:00.02 /var/named/named -u bind -g bind -t /var/named -- Yan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sandbox??
On Mon, 26 Jul 1999, Sue Blake wrote: If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sandbox??
Hi clever people Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: In article 19990719212431.d...@welearn.com.au, Sue Blake s...@welearn.com.au wrote: : Could someone tell me what is a sandbox, what does it do, how does it : work, how do I use it, or where is it documented? : named(8) and security(8) seem to assume one already knows. It's a generic term. It refers to a restricted environment in which something is to be done. Exactly how a sandbox is implemented depends on the specific application. As you see it is far from the complete 4-5 part answer I need. The problem that I see is that our named.conf refers to this sandbox thing, implies that it is actually the default method for BIND in FreeBSD (I don't think it is though), and directs the user to man pages which don't provide the necessary info to be able to confidently (un)implement it. If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone who they teach (me if really necessary) needs to document it so that anyone seriously interested can figure it out on thier own (or at least accept the defaults with confidence), and then change at least the named.conf to point to that info. It sounds like a good idea, worth giving people the resources to use it. (Email cc would be appreciated) -- Regards, -*Sue*- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) :-) On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: In article 19990719212431.d...@welearn.com.au, Sue Blake s...@welearn.com.au wrote: : Could someone tell me what is a sandbox, what does it do, how does it : work, how do I use it, or where is it documented? : named(8) and security(8) seem to assume one already knows. It's a generic term. It refers to a restricted environment in which something is to be done. Exactly how a sandbox is implemented depends on the specific application. Without having read the references in the files you mentioned, here is my own take on sandbox. In some firewall books I have read, sandbox is used to refer to a machine connected to the net in a protected way. Basically, all packets to and from that machine go through a firewall. The machine, though inside the firewall, is isolated from the rest of the internal network. The sandbox can then be used to provide services in a more or less secure way. It cannot threat the internal network, because it can reach it even if breached, and it is not as exposed as it would be outside the firewall. If *think* this definition was given in the book by the TIS people, but, alas, I haven't read about firewalls in two years, and my firewall books are 12 thousand km away. And notice, too, that I'm *not* refering to the hacker's trap, whose name I can't recall right now. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Is it true that you're a millionaire's son who never worked a day in your life? Yeah, I guess so. Lemme tell you, son, you ain't missed a thing. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
A sandbox is a security term. It can mean two things: * A process which is placed inside a set of virtual walls that are designed to prevent someone who breaks into the process from being able to break into the wider system. The process is said to be able to play inside the walls. That is, nothing the process does in regards to executing code is supposed to be able to breech the walls so you do not have to do a detailed audit of its code to be able to say certain things about its security. The walls might be a userid, for example. This is the definition used in the security and named man pages. Take the 'ntalk' service, for example (see /etc/inetd.conf). This service used to run as userid root. Now it runs as userid tty. The tty user is a sandbox desiegned to make it more difficult for someone who has successfully hacked into the system via ntalk from being able to hack beyond that user id. * A process which is placed inside a simulation of the machine. This is more hard-core. Basically it means that someone who is able to break into the process may believe that he can break into the wider machine but is, in fact, only breaking into a simulation of that machine and not modifying any real data. The most common way to accomplish this is to build a simulated environment in a subdirectory and then run the processes in that directory chroot'd (i.e. / for that process is this directory, not the real / of the system). Another common use is to mount an underlying filesystem read-only and then create a filesystem layer on top of it that gives a process a seemingly writeable view into that filesystem. The process may believe it is able to write to those files, but only the process sees the effects -- other processes in the system do not, necessarily. An attempt is made to make this sort of sandbox so transparent that the user (or hacker) does not realize that he is sitting in it. UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is unlike Windows where a process can easily overwrite the address space of any other, leading to a crash. A UNIX process is owned by a patricular userid. If the userid is not the root user, it serves to firewall the process off from processes owned by other users. The userid is also used to firewall off on-disk data. -Matt Matthew Dillon dil...@backplane.com :Hi clever people : :Nobody seems to be confident about the answer to my post to -questions. :Below is the only public answer. It is typical of many private answers :I received from otherwise knowledgeable people willing to make a :partial educated guess but not willing to expose their ignorance :publicly. They're all keen to know whatever I can find out :-) : :On Mon, Jul 19, 1999 at 07:58:01AM -0400, T. William Wells wrote: : In article 19990719212431.d...@welearn.com.au, : Sue Blake s...@welearn.com.au wrote: : : Could someone tell me what is a sandbox, what does it do, how does it : : work, how do I use it, or where is it documented? : : named(8) and security(8) seem to assume one already knows. : : It's a generic term. It refers to a restricted environment in : which something is to be done. Exactly how a sandbox is : implemented depends on the specific application. : :As you see it is far from the complete 4-5 part answer I need. The :problem that I see is that our named.conf refers to this sandbox thing, :implies that it is actually the default method for BIND in FreeBSD (I :don't think it is though), and directs the user to man pages which :don't provide the necessary info to be able to confidently :(un)implement it. : :If nobody understands how this sandbox thing works, we should change :the named.conf that we supply. If somebody does, then they or someone :who they teach (me if really necessary) needs to document it so that :anyone seriously interested can figure it out on thier own (or at least :accept the defaults with confidence), and then change at least the :named.conf to point to that info. It sounds like a good idea, worth :giving people the resources to use it. : :(Email cc would be appreciated) : :-- : :Regards, :-*Sue*- : To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
Sue Blake wrote: Nobody seems to be confident about the answer to my post to -questions. Below is the only public answer. It is typical of many private answers I received from otherwise knowledgeable people willing to make a partial educated guess but not willing to expose their ignorance publicly. They're all keen to know whatever I can find out :-) The usual use of the term sandbox means restricted environment. A chroot(3) can be used to build this, and jail(3) is a stronger version, although this is not a usual use for the term. The term is popular in Java where it it implies that the (possibly hostile) applet _cannot_ do anything dangerous, because the environment it runs in has no API that allows this (like the applet cannot open arb files). The term sandbox in inetd.conf refers to a su - safe_user; chroot safe_dir; app environment (I think) so that app cannot do any damage even if compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
Speaking of jail() ... it might be a good idea to change the int32 being passed for the IP address to something a little more portable or it will not be useable when IPV6 goes in. Perhaps a pointer and a length instead of an int32, or even pass a structural pointer and a length (which can remain backwards compatible by checking the passed length). -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
On Sun, Jul 25, 1999 at 11:36:49AM -0700, Matthew Dillon dil...@apollo.backplane.com wrote: A sandbox is a security term. It can mean two things: [...] UNIX implements two core sanboxes. One is at the process level, and one is at the userid level. Every UNIX process is completely firewalled off from every other UNIX process. One process can modify the address space of another. This is Can not. Silly typo ;) BTW, I have running bind running chroot()'ed in /var/named (where OpenBSD puts it). Can we now also put /var/named and all subdirs needed into FreeBSD? We can also add '-t /var/named' flag into commented out rc.conf startup for bind. I could supply more info to someone who can commit this into the tree... % tail /var/named/var/log/named-noise.log 25-Jul-1999 04:11:16.730 security: info: chrooted to /var/named 25-Jul-1999 04:11:16.871 security: info: group = bind 25-Jul-1999 04:11:16.872 security: info: user = bind % ps ax | grep named 113 ?? Is 0:00.02 /var/named/named -u bind -g bind -t /var/named -- Yan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
On Mon, 26 Jul 1999, Sue Blake wrote: If nobody understands how this sandbox thing works, we should change the named.conf that we supply. If somebody does, then they or someone Understanding a sandbox only requires the ability to read on the part of the user (something anyone in charge of named administration has hopefully learned, else they don't need to be administrating anything). As for the current named.conf format... I agree that it should be changed. Rc.conf currently references the fact that 'it may be possible to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a sandbox'. Saying FreeBSD does something one place while saying it may be possible to do it in another is... silly. The actual use is up to the administrator, so it seems logical to have named.conf examples for sandbox and non-sandbox configs. Mike Hoskins m...@adept.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sandbox??
:Understanding a sandbox only requires the ability to read on the part of :the user (something anyone in charge of named administration has hopefully :learned, else they don't need to be administrating anything). : :As for the current named.conf format... I agree that it should be :changed. Rc.conf currently references the fact that 'it may be possible :to run named in a sandbox'. Named.conf says 'FreeBSD runs bind in a :sandbox'. Saying FreeBSD does something one place while saying it may be :possible to do it in another is... silly. : :The actual use is up to the administrator, so it seems logical to have :named.conf examples for sandbox and non-sandbox configs. : :Mike Hoskins :m...@adept.org The sandbox code for bind is not a novice exercise, which is why it is commented out by default. This is mainly because bind insists on doing things which make sandboxing difficult - you can't HUP it, for example, or bring interfaces down and up. The comment in the sample named.conf is wrong, it isn't on by default. Bind has a number of design faults that make it difficult to run outside of root. It would probably work in a jail(), though, if someone wants to work on that. The sandbox for the comsat and ntalk daemons does work and is on by default. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
