Re: chroot administration

2002-08-17 Thread Branden Robinson
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

2002-08-16 Thread Thomas Bushnell, BSG
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

2002-08-16 Thread Ben Pfaff
[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

2002-08-16 Thread Thomas Bushnell, BSG
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]

2002-08-15 Thread Sam Vilain
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]

2002-08-15 Thread Russell Coker
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

2002-08-15 Thread John Hasler
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

2002-08-15 Thread Shaya Potter
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

2002-08-15 Thread John Hasler
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

2002-08-15 Thread Russell Coker
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

2002-08-15 Thread John Hasler
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

2002-08-15 Thread Russell Coker
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

2002-08-14 Thread Russell Coker
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

2002-08-14 Thread Sam Vilain
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

2002-08-14 Thread Shaya Potter
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

2002-08-14 Thread Shaya Potter
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

2002-08-14 Thread Russell Coker
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

2002-08-14 Thread Russell Coker
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

2002-08-14 Thread Michael Stone
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

2002-08-14 Thread Russell Coker
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

2002-08-14 Thread John Hasler
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

2002-08-14 Thread Craig Dickson
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

2002-08-14 Thread Russell Coker
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

2002-08-13 Thread Colin Walters
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

2002-08-13 Thread Shaya Potter
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.