svn commit: r367280 - head/lib/libc/gen

[Stefan Esser]

Am 04.11.20 um 20:49 schrieb Konstantin Belousov:
> On Mon, Nov 02, 2020 at 11:51:12PM +0100, Stefan Esser wrote:
>> Am 02.11.20 um 23:10 schrieb Konstantin Belousov:
>>> On Mon, Nov 02, 2020 at 10:49:07PM +0100, Emmanuel Vadot wrote:
>>>>    I think that the first question we want to ask is : Do we want to
>>>> support LOCALBASE being different than /usr/local
>>>>    I honestly don't see any advantages of making it !=/usr/local/ and
>>>> before we start putting a lot of new/useless(for I guess 99% of our
>>>> user base) in the tree we should here why people are using /usr/pkg or
>>>> whatever weird location.
>>>>    If they have some good argument, then we should proceed further.
>>>
>>> I would be delighted to be able to install _and use_ two independent
>>> set of packages from the same base system install.  Without recursing
>>> to jails, X forwarding, etc.
>>
>> I understand the use case, and I agree this may be appropriate for
>> a development system.
>>
>> But on a production system I'd never want to have a non-constant and
>> not generally applied LOCALBASE, at least not on a system that gives
>> a CLI to unprivileged users. Those could build their own copy of the
>> LOCALBASE tree (e.g. sym-linking all sub-trees that are to be kept
>> unmodified, replacing config files that policies that restrict the
>> user).
> So how this makes attitude to the feature different ?  For me, dev machine
> is my production box because what I do is development.  And for user that
> need to run an old binary-only 32bit app which requires X libs, for instance,
> it also would be a production.

Maybe I'm using the term in a too strict sense, but it has been
consistently used in this way in all the environments I have worked
in during the last few decades:

The term "production server" is generally applied to systems that
are operated by e.g. an admin team (e.g. ITIL operations processes).

You may consider your development work productive ;-), but that does
not make your development system a production system as found e.g.
in a server farm providing internal or public services.

One difference between test&development vs. production systems is
that development systems are generally operated under less tight
security obligations. You are in full control of the system and
could damage its integrity at will. It does not contain any data
you are not authorized to access.

The opposite is true of most "production systems", which need to
be protected against attacks on confidentiality, integrity, and
availability.

>> And if LOCALBASE is not compiled into binaries but somehow obtained
>> at run-time, there are a number of attacks I can imagine (e.g. by
>> LD_PRELOAD replace the sysctl() call in libc by your own version).
> If somebody can LD_PRELOAD their into your process, it makes no sense to talk
> about 'security'.

Yes, it takes some effort, but you could e.g. intercept fopen() calls
and manipulate the file name argument.

One of the suggested methods to make programs use a non-default
LOCALBASE was by means of an environment variable, and that makes it
trivial to have programs use an attacker-controlled value compare to
a LD_PRELOAD attack, though. This is acceptable on a development
system, but not on a production system, IMHO.

I'm afraid that sysctl() could be intercepted, if it was used to
determine a run-time value for LOCALBASE, but intercepting fopen()
could accomplish the same result even for hard-coded paths ...

>>> In fact I would like to use /usr/local and e.g /usr/local-i386 on amd64
>>> machine.  I am fine with me building both of them in my instance of
>>> poudriere.
>>
>> This is a use-case for architecture dependent path definitions (which
>> I have used some 30 years ago on HP-UX which supported 68k and HP-PA
>> on a single file system that way). Such a feature has been discussed
>> in FreeBSD multiple times over the decades ...
> 
> Ok, let replace /usr/local-i386 by /usr/local-11.4, if you so inclined.

Well, how about /compat/11.4-i386 then?

The HP-UX implementation used e.g. /usr/bin/@hppa/ ... and when a file
name lookup for /usr/bin/somefile did not find it in /usr/bin, it would
try /usr/bin/@ARCH (with ARCH = hppa or 68k, IIRC).

This is not exactly what you asked for, but our Linux emulation might
already contain everything required to allow a 32 bit environment to
exist on a 64 bit system. And by that I mean not the ability to execute
32 bin binaries that we already have, but e.g. to make path lookups by
such binaries consider the compat prefix first.

Ports built in the 32 bit environment should then find all their include
files, libraries ... under the appropriate /compat sub-tree.

That still leaves a few aspects undefined though, e.g. whether config
files in /etc or $LOCALBASE/etc will be different in the "emulation", or
shared with the base system. The same applies to /usr/share, which ought
to be architecture independent.

This could be an alternative layout to e.g. having 32 bit libraries in
/usr/lib32 (with both supported for backwards compatibility).

Regards, STefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20201105/80fe72ec/attachment.sig>