[arch-general] RPM Question

[C Anthony Risinger]

On Oct 3, 2010, at 4:59 PM, "Dan Vrátil" <vratil at progdansoft.com>
wrote:

> On Sun, 03 Oct 2010 14:21:28 -0700, Lew Wolfgang
> <wolfgang at sweet-haven.com> wrote:
>> On 10/03/2010 01:29 PM, Dan Vrátil wrote:
>>> On Sun, 03 Oct 2010 12:19:30 -0700, Lew Wolfgang
>>> <wolfgang at sweet-haven.com>  wrote:
>>>> On 10/03/2010 11:11 AM, Dan Vrátil wrote:
>>>>> On Sun, 03 Oct 2010 09:00:08 -0700, Lew Wolfgang
>>>>> <wolfgang at sweet-haven.com>   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 at progdansoft.com
> Tel: +4202 732 326 870
> Jabber: progdan at jabber.cz
>
> 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]