Re: chroot administration
On Thu, Aug 15, 2002 at 12:16:41PM -0500, John Hasler wrote: Perhaps it would be possible to use the FOIA to get the terms of the contract? Bwa ha ha ha, it has been the Bush administration's directive to all Federal agencies since BEFORE September 11th of last year to flush all FOIA requests down the toilet. -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks pgp2AQGRpEVEc.pgp Description: PGP signature
Re: chroot administration
John Hasler [EMAIL PROTECTED] writes: The US government definitely is allowed to own copyrights. The restriction is on _enforcing_ their copyrights on works of which they are author. There are two ways to be the owner of a copyright. First, you can buy it from someone else (or otherwise get it by transfer). The US government can own copyrights this way. The second way is by writing something. The US government cannot own copyrights this way. But this is not a restriction merely on enforcement, rather, no copyright at all exists. As evidence, I cite the following, 17 USC 105: Copyright protection under this title is not available for any work of the United States Government, but the United States Government is not precluded from receiving and holding copyrights transferred to it by assignment, bequest, or otherwise.
Re: chroot administration
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: John Hasler [EMAIL PROTECTED] writes: The US government definitely is allowed to own copyrights. The restriction is on _enforcing_ their copyrights on works of which they are author. There are two ways to be the owner of a copyright. First, you can buy it from someone else (or otherwise get it by transfer). The US government can own copyrights this way. The second way is by writing something. The US government cannot own copyrights this way. But this is not a restriction merely on enforcement, rather, no copyright at all exists. As evidence, I cite the following, 17 USC 105: Copyright protection under this title is not available for any work of the United States Government, but the United States Government is not precluded from receiving and holding copyrights transferred to it by assignment, bequest, or otherwise. The specific powers of the U.S. government listed there are receiving and holding. It does not mention enforcing or protecting, etc. Are those powers implied elsewhere?
Re: chroot administration
Ben Pfaff [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: John Hasler [EMAIL PROTECTED] writes: The US government definitely is allowed to own copyrights. The restriction is on _enforcing_ their copyrights on works of which they are author. There are two ways to be the owner of a copyright. First, you can buy it from someone else (or otherwise get it by transfer). The US government can own copyrights this way. The second way is by writing something. The US government cannot own copyrights this way. But this is not a restriction merely on enforcement, rather, no copyright at all exists. As evidence, I cite the following, 17 USC 105: Copyright protection under this title is not available for any work of the United States Government, but the United States Government is not precluded from receiving and holding copyrights transferred to it by assignment, bequest, or otherwise. The specific powers of the U.S. government listed there are receiving and holding. It does not mention enforcing or protecting, etc. Are those powers implied elsewhere? There is no such thing as the ownership of a copyright absent the right to enforce it. Such enforcement *is* what the ownership is.
Sandboxing Debian [was: Re: chroot administration]
Russell Coker [EMAIL PROTECTED] wrote: http://www.solucorp.qc.ca/miscprj/s_context.hc Is someone going to package this for Debian? One person has announced that he is going to try on the list, though they are not an official debian developer. I have made a package, too, and will make it available soon. There are some limitations with it. The biggest limitation when compared to my SE Linux work is it's lack of flexibility. I can setup a SE Linux chroot, then do a bind mount of /home/www, and grant read-only access to the files and directories of user_home_t and search access to directories of type user_home_dir_t. This stuff is accomplished through file immutability and Linux capabilities. It's not as flexible as the system you're describing sounds, but it does work with standard Linux filesystem features and represents a smaller departure from UNIX conventions. The advantage of the security contexts system described on that web page is a comprehensive solution to the IP address issue (I've got a design but no working code so far). I don't expect to ever get a solution that works as well as their solution unless/until new features are added to SE Linux. It's not perfect, though - due to a shocking case of C programmer's disease. One big problem is what to do with the `localhost' interface. Currently, you can't have a guaranteed private interface and expect applications to work. This is because the IP jailing works by intercepting the `bind' call, and remapping binds to 0.0.0.0 to the first IP address listed in our `ip chroot', as well as binds to 127.0.0.1. I tried adding an extra IP address - 127.0.0.X - to the IP chroot and defining that as `localhost' in /etc/hosts, and eventually after finding that SSH local port forwarding (to pick on an application for which it didn't work) was always trying to bind to 127.0.0.1, I found this gem in glibc: /* Network number for local host loopback. */ #define IN_LOOPBACKNET 127 /* Address to loopback in software to local host. */ #ifndef INADDR_LOOPBACK # define INADDR_LOOPBACK((in_addr_t) 0x7f01) /* Inet 127.0.0.1. */ #endif so the getaddrinfo() call will always return 127.0.0.1 for the local host. Which is a bit of an arse really, but I think I'd probably just get laughed at or ignored if I logged a bug against it. But if you don't mind `localhost' being the same as your external IP address there's no problem.
Re: Sandboxing Debian [was: Re: chroot administration]
On Thu, 15 Aug 2002 12:50, Sam Vilain wrote: There are some limitations with it. The biggest limitation when compared to my SE Linux work is it's lack of flexibility. I can setup a SE Linux chroot, then do a bind mount of /home/www, and grant read-only access to the files and directories of user_home_t and search access to directories of type user_home_dir_t. This stuff is accomplished through file immutability and Linux capabilities. It's not as flexible as the system you're describing sounds, but it does work with standard Linux filesystem features and represents a smaller departure from UNIX conventions. True. I tried adding an extra IP address - 127.0.0.X - to the IP chroot and defining that as `localhost' in /etc/hosts, and eventually after finding that SSH local port forwarding (to pick on an application for which it didn't work) was always trying to bind to 127.0.0.1, I found this gem in glibc: /* Network number for local host loopback. */ #define IN_LOOPBACKNET 127 /* Address to loopback in software to local host. */ #ifndef INADDR_LOOPBACK # define INADDR_LOOPBACK ((in_addr_t) 0x7f01) /* Inet 127.0.0.1. */ #endif so the getaddrinfo() call will always return 127.0.0.1 for the local host. Which is a bit of an arse really, but I think I'd probably just get laughed at or ignored if I logged a bug against it. I think you should file a bug report. /etc/hosts contains an entry for localhost on every system. What is the point of this if glibc is to do it? If glibc wants to fudge in a value AFTER checking /etc/hosts and finding no match then that would be OK. But doing it unconditionally is wrong. Of course you probably will get laughed at or ignored, but I think that many people will agree with you, so you should file the bug report. -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
Russell Coker writes: If software can't be freely used for any purpose then it can't be released under the GPL. The NSA assert that they have the right to release under the GPL and that therefore the patent issues have been dealt with. Was the work done by NSA employees? If so it can be treated as if it were in the public domain no matter what license NSA attaches to it (that's NSAs work in isolation, of course, not the modified kernel as a whole). As for the Section 7 issue, note that a court judgement or allegation of infringement must 'impose conditions'. Has this happened? If so the other kernel authors may have grounds to sue to stop distribution by whomever the connditions have been imposed upon. If the SCC directly challenge this then they will immediately face the DoJ. SCC can sue you for infringing their patent without sueing NSA, no matter what licensing arrangement you have with NSA. The copyright is irrelevant to the patents. That is what I meant by 'orthogonal'. IMHO until SCC actually initiates legal action their is no GPL violation. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: chroot administration
On Thu, 2002-08-15 at 11:02, John Hasler wrote: Russell Coker writes: If software can't be freely used for any purpose then it can't be released under the GPL. The NSA assert that they have the right to release under the GPL and that therefore the patent issues have been dealt with. Was the work done by NSA employees? If so it can be treated as if it were in the public domain no matter what license NSA attaches to it (that's NSAs work in isolation, of course, not the modified kernel as a whole). As for the Section 7 issue, note that a court judgement or allegation of infringement must 'impose conditions'. Has this happened? If so the other kernel authors may have grounds to sue to stop distribution by whomever the connditions have been imposed upon. not 100% sure about that. At least when I worked at NRL, I thought it created this murky situation of public domain for us citizens (or in US not sure which) but not for anyone else. maybe I didnt understand it correctly.
Re: chroot administration
Shaya Potter writes: At least when I worked at NRL, I thought it created this murky situation of public domain for us citizens (or in US not sure which) but not for anyone else. In the US works of the US government are public domain for everyone. However, it might be able to obtain and enforce copyrights in the jurisdictions of other governments. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: chroot administration
On Thu, 15 Aug 2002 17:38, John Hasler wrote: Shaya Potter writes: At least when I worked at NRL, I thought it created this murky situation of public domain for us citizens (or in US not sure which) but not for anyone else. In the US works of the US government are public domain for everyone. However, it might be able to obtain and enforce copyrights in the jurisdictions of other governments. I don't think that it is possible for them to get a copyright in another jurisdiction without getting one in their own. As the US government is prohibited from owning copyright they definately can't get a copyright in their own jurisdiction, and possibly can't apply for one in another jurisdiction (depending on interpretation). On Thu, 15 Aug 2002 17:02, John Hasler wrote: Russell Coker writes: If software can't be freely used for any purpose then it can't be released under the GPL. The NSA assert that they have the right to release under the GPL and that therefore the patent issues have been dealt with. Was the work done by NSA employees? If so it can be treated as if it were in the public domain no matter what license NSA attaches to it (that's NSAs work in isolation, of course, not the modified kernel as a whole). As for the Section 7 issue, note that a court judgement or allegation of infringement must 'impose conditions'. Has this happened? If so the other kernel authors may have grounds to sue to stop distribution by whomever the connditions have been imposed upon. The NSA paid a sum of money (rumored to be $2M) to SCC to write a Linux kernel patch to be distributed under the GPL which implements their patents. The issue is that SCC was paid to write code for GPL release. Claiming otherwise would probably be a breach of their contract with the NSA... -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
Russell Coker writes: As the US government is prohibited from owning copyright they definately can't get a copyright in their own jurisdiction,... The US government definitely is allowed to own copyrights. The restriction is on _enforcing_ their copyrights on works of which they are author. ...and possibly can't apply for one in another jurisdiction (depending on interpretation). And on the jurisdiction. The NSA paid a sum of money (rumored to be $2M) to SCC to write a Linux kernel patch to be distributed under the GPL which implements their patents. Then most likely either SCC owns the copyright or they assigned it to NSA. The issue is that SCC was paid to write code for GPL release. Claiming otherwise would probably be a breach of their contract with the NSA... Which only NSA can enforce. My first guess is that if SCC were to start enforcing its patents against you then Linus et al could sue NSA to stop distributing the patched kernel and NSA in turn could sue SCC for specific performance. Perhaps it would be possible to use the FOIA to get the terms of the contract? Maybe NSA's lawyers already thought of all this. I think it is perfectly legal and safe to distribute and use the patches now, but it seems possible that SCC could start enforcing its patents at any time, thereby stopping distribution. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: chroot administration
On Thu, 15 Aug 2002 19:16, John Hasler wrote: Russell Coker writes: As the US government is prohibited from owning copyright they definately can't get a copyright in their own jurisdiction,... The US government definitely is allowed to own copyrights. The restriction is on _enforcing_ their copyrights on works of which they are author. I have been told otherwise, but as I am not a lawyer I have to admit the possibility that I misunderstood what I was told. Are you a lawyer? If not then I'll disregard your statements on this matter because the information I received came from someone who should know. The NSA paid a sum of money (rumored to be $2M) to SCC to write a Linux kernel patch to be distributed under the GPL which implements their patents. Then most likely either SCC owns the copyright or they assigned it to NSA. I am under the impression that perhaps the issue of copyright ownership was not made clear, however the issue of GPL release was. The issue is that SCC was paid to write code for GPL release. Claiming otherwise would probably be a breach of their contract with the NSA... Which only NSA can enforce. My first guess is that if SCC were to start enforcing its patents against you then Linus et al could sue NSA to stop distributing the patched kernel and NSA in turn could sue SCC for specific performance. If SCC sued anybody then it would kill SE Linux, and thus waste a significant amount of NSA resources (I'd have to guess at least $10M has been spent on this). The best way for SCC to bring trouble upon themselves would be to sue me. I believe am doing more for the widespread acceptance of SE Linux than anyone outside the NSA. Also if SCC wants to sue me then they have to do it in Amsterdam, bwahahahaha... Perhaps it would be possible to use the FOIA to get the terms of the contract? It may be possible for someone who is a US citizen. If someone gets a copy of such a contract then I wouldn't mind if it got email'd to me... NB I am specifically not requesting that someone obtain a copy of the contract for the purpose of giving it to me. However if it's available I wouldn't mind a copy. Maybe NSA's lawyers already thought of all this. I think it is perfectly legal and safe to distribute and use the patches now, but it seems possible that SCC could start enforcing its patents at any time, thereby stopping distribution. True. However there is another issue. It is widely believed that the Chinese are doing some serious SE Linux work. It would be a bit of an annoyance for the US government if US interests can't be protected by the NSA's software while Chinese interests can be. With the current political climate in the US you wouldn't want to be the party responsible for giving the Chinese better info-sec than the US... -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
On Wed, 14 Aug 2002 05:35, Shaya Potter wrote: On Tue, 2002-08-13 at 22:09, Colin Walters wrote: On Tue, 2002-08-13 at 17:48, Russell Coker wrote: I have written SE Linux policy for administration of a chroot environment. That allows me to give full root administration access (ability to create/delete users, kill processes running under different UIDs, ptrace, etc) to a chroot environment without giving any access to the rest of the system. Since no one else has apparently said it explictly yet, I have to say that's extremely cool :) Thanks Colin. argh. its so cool that you essentially stole my summer research. :(. Does this allow you to create any amount of chroot jails? We are also It allows the administrator to create any number of chroot jail setups for a given user, and they can set them up for as many users as they like. working on making virtual IPs that each jail would get. We are also working on being able to move the processes while running (w/ network connections) from machine to machine w/o needing any state on initial machine. I am not planning to work on moving processes etc. If you'd like to build on top of my work then you are welcome, it'll all be in Debian in a few days. -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
Shaya Potter [EMAIL PROTECTED] wrote: I have written SE Linux policy for administration of a chroot environment. That allows me to give full root administration access (ability to create/delete users, kill processes running under different UIDs, ptrace, etc) to a chroot environment without giving any access to the rest of the system. Since no one else has apparently said it explictly yet, I have to say that's extremely cool :) argh. its so cool that you essentially stole my summer research. :(. Does this allow you to create any amount of chroot jails? We are also working on making virtual IPs that each jail would get. We are also working on being able to move the processes while running (w/ network connections) from machine to machine w/o needing any state on initial machine. You might want to investiage `security contexts', a new kernel feature that can be used for virtual IP roots as well as making processes in one context (even root) not able to see other contexts' processes. The userland utilities also offer a way to remove Linux's capabilities (eg, to disallow raw sockets or bypassing filesystem permissions). http://www.solucorp.qc.ca/miscprj/s_context.hc -- Sam Vilain, [EMAIL PROTECTED] Easyspace: an accredited ICANN GPG: http://sam.vilain.net/sam.ascregistrar web hosting company 7D74 2A09 B2D3 C30F F78E Have your domain run by techies 278A A425 30A9 05B5 2F13 with a clue. www.easyspace.com Ambition is the curse of the political class. - anon.
Re: chroot administration
btw, when I said stole i didnt mean it to be harsh. sorry if it came off that way. shaya On Wed, 2002-08-14 at 04:26, Russell Coker wrote: On Wed, 14 Aug 2002 05:35, Shaya Potter wrote: On Tue, 2002-08-13 at 22:09, Colin Walters wrote: On Tue, 2002-08-13 at 17:48, Russell Coker wrote: I have written SE Linux policy for administration of a chroot environment. That allows me to give full root administration access (ability to create/delete users, kill processes running under different UIDs, ptrace, etc) to a chroot environment without giving any access to the rest of the system. Since no one else has apparently said it explictly yet, I have to say that's extremely cool :) Thanks Colin. argh. its so cool that you essentially stole my summer research. :(. Does this allow you to create any amount of chroot jails? We are also It allows the administrator to create any number of chroot jail setups for a given user, and they can set them up for as many users as they like. working on making virtual IPs that each jail would get. We are also working on being able to move the processes while running (w/ network connections) from machine to machine w/o needing any state on initial machine. I am not planning to work on moving processes etc. If you'd like to build on top of my work then you are welcome, it'll all be in Debian in a few days. -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
On Wed, 2002-08-14 at 06:50, Sam Vilain wrote: Shaya Potter [EMAIL PROTECTED] wrote: I have written SE Linux policy for administration of a chroot environment. That allows me to give full root administration access (ability to create/delete users, kill processes running under different UIDs, ptrace, etc) to a chroot environment without giving any access to the rest of the system. Since no one else has apparently said it explictly yet, I have to say that's extremely cool :) argh. its so cool that you essentially stole my summer research. :(. Does this allow you to create any amount of chroot jails? We are also working on making virtual IPs that each jail would get. We are also working on being able to move the processes while running (w/ network connections) from machine to machine w/o needing any state on initial machine. You might want to investiage `security contexts', a new kernel feature that can be used for virtual IP roots as well as making processes in one context (even root) not able to see other contexts' processes. The userland utilities also offer a way to remove Linux's capabilities (eg, to disallow raw sockets or bypassing filesystem permissions). yea, I know all about it, but thats a bit more involved than what we want/need. I looked at that already. Might take another look at it again later, but it seemed too much for our needs, and therefore a little heavy. debian
Re: chroot administration
On Wed, 14 Aug 2002 12:50, Sam Vilain wrote: argh. its so cool that you essentially stole my summer research. :(. Does this allow you to create any amount of chroot jails? We are also working on making virtual IPs that each jail would get. We are also working on being able to move the processes while running (w/ network connections) from machine to machine w/o needing any state on initial machine. You might want to investiage `security contexts', a new kernel feature that can be used for virtual IP roots as well as making processes in one context (even root) not able to see other contexts' processes. The userland utilities also offer a way to remove Linux's capabilities (eg, to disallow raw sockets or bypassing filesystem permissions). http://www.solucorp.qc.ca/miscprj/s_context.hc Is someone going to package this for Debian? There are some limitations with it. The biggest limitation when compared to my SE Linux work is it's lack of flexibility. I can setup a SE Linux chroot, then do a bind mount of /home/www, and grant read-only access to the files and directories of user_home_t and search access to directories of type user_home_dir_t. In my default policy I have given the user who starts the chroot environment full access to files and directories in the chroot (of course if their UID!=0 then they won't be able to do much). Also in my policy I have two different security domains, one for all programs which has limited write access, and another for administration tools (such as dpkg/dselect) which can write all files and directories. I could make an addition to this and have another file type which is append-only for the ordinary chroot domain and can only be read by the user who starts the chroot and the super domain. This would greatly limit the ability of someone who breaks the security of a chroot environment. The advantage of my work is that it's all in policy files that can easily be changed - you could even change the policy at run-time and grant different permissions to running processes! The advantage of the security contexts system described on that web page is a comprehensive solution to the IP address issue (I've got a design but no working code so far). I don't expect to ever get a solution that works as well as their solution unless/until new features are added to SE Linux. -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
On Wed, 14 Aug 2002 14:47, you wrote: btw, when I said stole i didnt mean it to be harsh. sorry if it came off that way. No probs, I didn't take any offense. I'd be happy to work with you on developing such things if your interests are similar to mine. -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
On Wed, Aug 14, 2002 at 11:50:14AM +0100, Sam Vilain wrote: You might want to investiage `security contexts', a new kernel feature that can be used for virtual IP roots as well as making processes in one context (even root) not able to see other contexts' processes. The userland utilities also offer a way to remove Linux's capabilities (eg, to disallow raw sockets or bypassing filesystem permissions). http://www.solucorp.qc.ca/miscprj/s_context.hc Does this avoid selinux's patent encumbrance issues? -- Mike Stone
Re: chroot administration
On Wed, 14 Aug 2002 15:47, Michael Stone wrote: On Wed, Aug 14, 2002 at 11:50:14AM +0100, Sam Vilain wrote: You might want to investiage `security contexts', a new kernel feature that can be used for virtual IP roots as well as making processes in one context (even root) not able to see other contexts' processes. The userland utilities also offer a way to remove Linux's capabilities (eg, to disallow raw sockets or bypassing filesystem permissions). http://www.solucorp.qc.ca/miscprj/s_context.hc Does this avoid selinux's patent encumbrance issues? It's offering the same functionality as BSD jail only so the patents in question don't apply. They don't apply to SE Linux either, the NSA says that SE Linux is licensed under the GPL only. If anyone wants to dispute that then they have to sue the NSA... -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
Russell Coker writes: They don't apply to SE Linux either, the NSA says that SE Linux is licensed under the GPL only. If anyone wants to dispute that then they have to sue the NSA... The licensing of the software is orthogonal to the licensing of the patents. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: chroot administration
John Hasler wrote: Russell Coker writes: They don't apply to SE Linux either, the NSA says that SE Linux is licensed under the GPL only. If anyone wants to dispute that then they have to sue the NSA... The licensing of the software is orthogonal to the licensing of the patents. Not entirely. See Section 7 of the GPL. Craig pgp2Lxx9UkyW9.pgp Description: PGP signature
Re: chroot administration
On Wed, 14 Aug 2002 19:50, John Hasler wrote: Russell Coker writes: They don't apply to SE Linux either, the NSA says that SE Linux is licensed under the GPL only. If anyone wants to dispute that then they have to sue the NSA... The licensing of the software is orthogonal to the licensing of the patents. If software can't be freely used for any purpose then it can't be released under the GPL. The NSA assert that they have the right to release under the GPL and that therefore the patent issues have been dealt with. If the SCC directly challenge this then they will immediately face the DoJ. -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field.
Re: chroot administration
On Tue, 2002-08-13 at 17:48, Russell Coker wrote: I have written SE Linux policy for administration of a chroot environment. That allows me to give full root administration access (ability to create/delete users, kill processes running under different UIDs, ptrace, etc) to a chroot environment without giving any access to the rest of the system. Since no one else has apparently said it explictly yet, I have to say that's extremely cool :)
Re: chroot administration
On Tue, 2002-08-13 at 22:09, Colin Walters wrote: On Tue, 2002-08-13 at 17:48, Russell Coker wrote: I have written SE Linux policy for administration of a chroot environment. That allows me to give full root administration access (ability to create/delete users, kill processes running under different UIDs, ptrace, etc) to a chroot environment without giving any access to the rest of the system. Since no one else has apparently said it explictly yet, I have to say that's extremely cool :) argh. its so cool that you essentially stole my summer research. :(. Does this allow you to create any amount of chroot jails? We are also working on making virtual IPs that each jail would get. We are also working on being able to move the processes while running (w/ network connections) from machine to machine w/o needing any state on initial machine.
