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]
