----- Original message ----- > On Oct 3, 2010, at 4:59 PM, "Dan Vrátil" <vratil@xxxxxxxxxxxxxxx> > wrote: > > > On Sun, 03 Oct 2010 14:21:28 -0700, Lew Wolfgang > > <wolfgang@xxxxxxxxxxxxxxx> wrote: > > > On 10/03/2010 01:29 PM, Dan Vrátil wrote: > > > > On Sun, 03 Oct 2010 12:19:30 -0700, Lew Wolfgang > > > > <wolfgang@xxxxxxxxxxxxxxx> wrote: > > > > > On 10/03/2010 11:11 AM, Dan Vrátil wrote: > > > > > > On Sun, 03 Oct 2010 09:00:08 -0700, Lew Wolfgang > > > > > > <wolfgang@xxxxxxxxxxxxxxx> wrote: > > > > > > > On 10/02/2010 06:10 PM, Steven Susbauer wrote: > > > > > > > > On 10/2/2010 7:41 PM, Lew Wolfgang wrote: > > > > > > > > > It works on all the major distros but fails to install > > > > > > > > > on Arch due to an RPM dependency. Their install script > > > > > > > > > just fails saying > > > > > > > > > it can't find rpm. The script contains much ugliness and > > > > > > > > > is McAfee > > > > > > > > > proprietary, so I doubt hacking it will be productive. > > > > > > > > > > > > > > > > > > So the question is: can Arch be configured/tricked into > > > > > > > > > an rpm install? > > > > > > > > Does their installer actually require use rpm to install, > > > > > > > > or just wants rpm to be> there? Most distros allow you to > > > > > > > > install rpm, Arch is no different except it is in> aur: > > > > > > > > > > > > > > > > aur/rpm 5.2.1-1 (153) > > > > > > > > The RedHat Package Manager. Don't use it instead of > > > > > > > > Arch's 'pacman'. > > > > > > > > > > > > > > > > If it actually uses rpm for the process, this is probably > > > > > > > > not the solution. Two> package managers at once is not a > > > > > > > > good thing. > > > > > > > I spent some time last night pulling the .sh file apart. > > > > > > > It's a script that unzips a binary that unpacks two rpm > > > > > > > files (9-MB), one > > > > > > > 32-bit ELF program (8.9-MB), two cryptographic keys and an > > > > > > > xml file. > > > > > > > The script then calls rpm to install the two rpm files, which > > > > > > > contain > > > > > > > tons of 32-bit system libraries. These libraries have the > > > > > > > same names > > > > > > > as regular system libs, like libc, libm, libresolv and > > > > > > > libcrypt. This > > > > > > > all makes me very nervous! Arch not using rpm may be a > > > > > > > blessing in > > > > > > > disguise, I'm going to see if I can get a waiver to not > > > > > > > install this > > > > > > > McAfee root-kit. > > > > > > > > > > > > > > Thanks for the help, > > > > > > > Lew > > > > > > What about setting up a simple tiny chroot just for this > > > > > > application? > > > > > > > > > > > > > > > > > That's an interesting idea, Dan. But since this package is > > > > > supposed > > > > > to install itself like a cancer in the OS, it wouldn't be able to > > > > > perform its function in a chroot. The Windows version of this > > > > > thing > > > > > is intended to remove local administrative privileges so that the > > > > > machine can be completely managed remotely. It can prevent > > > > > unapproved > > > > > programs from being loaded, and can disable installed programs > > > > > that it > > > > > has an issue with. Indeed, it disabled non-current versions of > > > > > Adobe > > > > > Acrobat a couple of weeks ago. It also has an IPS function to > > > > > monitor > > > > > and disable network traffic it finds threatening. It can enforce > > > > > password polices and can report what a user is doing and what web > > > > > sites they're visiting. It can sniff network configurations and > > > > > report dual-homed hosts, natted subnets are also disallowed. > > > > > I'm sure it does much more. I've been told that the Linux/Apple > > > > > versions > > > > > only report at this time, the more intrusive capabilities aren't > > > > > yet > > > > > implemented. > > > > > > > > > > Thanks, > > > > > Lew > > > > Well it is just an application, not a kernel module or so, so in my > > > > opinion > > > > it does not matter if it runs in chroot or not, as it can only > > > > obtain > > > > datas > > > > from some /proc, /sys and /dev files and these can be made > > > > available in the chroot via mount (e.g. by mounting the real > > > > folders to the chroot). > > > > What I want to say is, that the application can have access to all > > > > the > > > > informations > > > > it wants, but it will just be installed separately from your > > > > beloved Arch. > > > > > > > > > > > Hi Dan, > > > > > > Interesting. I wonder how one would do this? Since the package > > > depends on RPM, could that be installed in a jail and not interfere > > > with pacman? Or would most of a second OS need to live in the jail? > > > Can you install a full-up Fedora or openSuSE in a jail? The jail > > > would need access to the main /etc/passwd and /etc/shadow files, > > > wouldn't that be rather difficult to set up? A chroot that has full > > > access to /? Interesting to contemplate... > > > > > > Regards, > > > Lew > > > > Actually that should not be so difficult to set up. You can use > > program > > called "schroot". It mounts the real folder (/home, /dev, /proc etc) > > to > > the > > chroot using fstab-like file (see /etc/schroot/mount-arch32) and it > > also > > copies some essential files (like /etc/shadow and /etc/passwd) to the > > chroot > > (see /etc/schroot/copyfiles-arch32). > > > > Additionally, I think you don't need access to full /, just to /etc, > > /dev, /sys > > and /proc since that's all where the program can get any useful info > > or > > > > where any essential data to be watched over are located. If I'm wrong, > > it's not a problem to mount the folder to the chroot filesystem. > > The rest of the chroot's filesystem can contain whatever you want. > > Actually I believe that it should work even when you would have only > > the libs that the program is linked against and some applications that > > the program needs to run, you don't even have to install kernel, udev, > > etc. > > > > I'd recommend not to even use pacman to set up the chroot, but use RPM > > to set it all up from the main system, something like: > > > > rpm install base-system --root=/home/chroot > > --dbpath=/home/chroot/var/lib/packages > > (I don't know how to use rpm, just to show the idea) > > > > and then enter the chroot using > > > > schroot -c my_chroot > > > > and then just start the application from the chroot. > > > > Dan > > > > -- > > -- > > Dan Vrátil > > vratil@xxxxxxxxxxxxxxx > > Tel: +4202 732 326 870 > > Jabber: progdan@xxxxxxxxx > > > > Tento email neobsahuje žádné viry, protože odesílatel nepouží > > vá > > Windows. / > > This email does not contain any viruses because the sender does not > > use > > Windows. > > If you want to be sure it can't escape, you could try using LXC to > contain the fedora system. > > It is a recent kernel technology designed specifically for this > purpose, and has tools to build fedora amongst other distributions. > > Very easy to set up a containerized system. > > C Anthony [mobile] Hmmm the LXC looks like a pretty cool project, that's exactly what I was looking for some time ago, thanks for bringing it in. But if I understood correctly, you need to have entire system installed inside the container, which is I think a waste of diskspace for just one program, meanwhile chroot would require just default libs, bash and dependencies of that app. Dan
