The 'user' way to address this is to modify LIBPATH variable - as I did
above, and that will work for a long time.
Starting with AIX 6.1 - this can be disabled by setting a security policy -
so that only programs and/or libraries can be executed from trusted
locations.
>From trustchk man page - three of the options for the -p (policy) flag
TE
Enables or disables Trusted Execution. Policies can only be
activated when the TE option is set to ON.
TEP
Sets the value of Trusted Execution path, and enables or
disables
it. The Trusted Execution path consists of a list of
colon-separated
absolute paths, for example, the /usr/bin:/usr/sbin. When this
policy is enabled, the files belonging to only these directory
paths
are allowed to be started. If an executable program that does
not
belong to the TEP is to be loaded, the program is blocked.
TLP
Sets the value of Trusted Library path, and enables or disables
it.
The Trusted Library Path consists of a list of colon-separated
absolute paths, for example, the /usr/lib:/usr/ccs/lib. When
this
policy is enabled, the libraries belonging to only these
directory
paths can be loaded. If a program tries to load a library that
does
not belong to the TLP, the program is blocked.
As an example - default settings (TE=off, so all are ignored)
michael@x071:[/data/prj/openbsd/openssh/openssh]trustchk -p TE TEP TLP
TE=OFF
TEP=OFF
TEP=/usr/bin:/usr/sbin:/etc:/bin:/sbin:/sbin/helpers/jfs2:/usr/lib/instl:/usr/ccs/bin:/usr/lib:/usr/lib/security:/usr/lib:/usr/lib/security:/etc/security
TLP=OFF
TLP=/usr/lib:/usr/ccs/lib:/lib:/var/lib:/usr/lib/drivers
re: the 'undesired behavior' of the AIX ld program. I would say it is
'still' there - and I agree with the premise that the default library
search path gets very messy. This is actually one of the reasons why I
started packaging tools myself (I did not like the state, nor the extra
libraries I needed to load, or overwrite 'AIX' ones (which broke other
things).
To underline this issue - without any -blibpath variable the default (in
the binary LIBPATH would be:
***Import File Strings***
INDEX PATH BASE
MEMBER
0
.:openbsd-compat/:/opt/libressl/lib:/usr/vac/lib:/usr/lib:/lib
1 libc.a
shr.o
2 libcrypto.a
libcrypto.so.32
Coming from - what ld already has a default plus these arguments:
-L. -Lopenbsd-compat/ -L/opt/libressl/lib
I am guessing that this is the behavior of 'other' linkers when -R is used.
As a packager - I would like the option to be able to specify the -blibpath
- especially because I want to be able to package 'aixtools' as a
replacement package that can co-exist - because I do not expect to resolve
all possible dependencies of existing programs. Additionally, if I used a
position 'owned' by another package - an update of that package may
overwrite what I have done.
The is the reason for /opt and/or /opt/package as prefix - older default is
/usr/local; IBM AIX toolkit and others use /opt/freeware/*
>From my perspective - when using a different version of 'openSSL API' - for
it to work I will need a different blibpath so it gets found. That is much
better than that I would add libcrypto.so.32 as a MEMBER to
/usr/lib/libcrypto.a
FYI: This is the IBM version on AIX 6.1
michael@x071:[/data/prj/openbsd/openssh/openssh]ar tv /usr/lib/libcrypto.a
rwxrwxr-x 435159/781431 2965832 May 01 06:57 2014 libcrypto.so.1.0.0
rwxrwxr-x 435159/781431 2253655 May 01 06:58 2014 libcrypto.so.0.9.8
I see not the most recent one - but the dual support, via dual members is
how that is working.
openssl.base 1.0.1.510 C F Open Secure Socket Layer
POSSIBILITIES:
just as you give a warning message for no use of compiler stack execution
protection - you could give a warning that a modified blibpath is being
used.
re: stack execution protection, AIX has a hardware based mechanism that can
be set system-wide and/or at application level. See
http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.security/stack_exec_disable.htm.
This has it's start back in 2004/2005 with POWER4 iirc.
I shall address va_copy in a second note.
On Fri, Feb 27, 2015 at 7:04 PM, Darren Tucker <dtucker@xxxxxxxxxx> wrote:
> On Fri, Feb 27, 2015 at 9:19 AM, Michael Felt <aixtools@xxxxxxxxx> wrote:
>>
>> One problem coming directly is that the -L flag (-L/opt/libressl/lib is
>> not
>> being included in the -blibpath so the programs link, but do not run.
>> I am sure there is a way for me to modify the blibpath - BUT - I ask you
>> do
>> consider inserting an openssl-dir path when it is not
>> already in the blibpath variable.
>>
>
> There's a reason why it isn't: where that directory is writeable by a
> non-root user it becomes a vector for local privilege escalation via
> OpenSSH's setuid binaries.
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2003-April/017768.html
>
> Now that decision was made back in the day when OpenSSL's shared library
> support was still considered experimental. Maybe we could check that the
> path is a) absolute and b) system-owned all the way down and add it to
> blibpath if both are true.
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
