lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 3 Jun 2008 19:43:57 +0200
From:	Bas Wijnen <wijnen@...ian.org>
To:	netconf developers list <netconf-devel@...ts.alioth.debian.org>
Cc:	netdev discussion list <netdev@...r.kernel.org>,
	Ben Hutchings <bhutchings@...arflare.com>
Subject: Re: non-root, non-real network manipulation for netconf testing

Hi,

On Tue, Jun 03, 2008 at 10:05:29AM +0200, martin f krafft wrote:
> Of course, I am asking a bit much, but maybe you guys have some
> input that could help us move along?

The best way would be to use the Hurd, and write a network device
emulator (which can be modified without messing up actual network
devices).  But I suppose that's not an option. ;-)

As a second option, I'd go for qemu.  It can be run as non-root and
communicate about its test results over the serial port (connected to
stdout).  However, building a qemu image takes a long time, and I think
you still need root for that.

> What I really want is some context handler that can emulate
> a complete network and process stack for my test scripts, let
> a normal user modify anything they want, but not touch anything on
> the actual system.

Qemu does all that, it emulates a whole computer with it. :-)

On Tue, Jun 03, 2008 at 12:20:50PM +0200, martin f krafft wrote:
> also sprach Ben Hutchings <bhutchings@...arflare.com> [2008.06.03.1205 +0200]:
> > Have you considering running the tests in User-Mode Linux or some
> > other kind of virtualised environment?
> 
> Yes, but that would require root rights as well, and quite a lot of
> setup, making it pretty unlikely that passerby developers would run
> tests, or allowing me to run the tests automatically on build
> daemons.

You can do all the setup automatically, so passerby developers don't
need to know how to do it.  However, the root rights (or, in case of
qemu, the heavy setup process) does probably make it impractical to do
it on a buildd, for example.

An option would be to create a dummy network device of the type I
described for the Hurd, but for Linux, and package that in a separate
package.  Netconf can build-depend on it, so it is installed (and can
make sure it is available for normal users).

However, I don't think Linux allows network interfaces to tell that
normal users may modify them...

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ