Re: DigitalOcean's BSD debut is FreeBSD only
2014-12-18 19:37 GMT+01:00 andrew fabbro : > On Thu, Dec 18, 2014 at 10:24 AM, Adam Thompson > wrote: >> >> The list of VPS providers where OpenBSD will run, more or less correctly, >> more or less all of the time, is actually very big. It will even run >> correctly all of the time on a fairly large list of providers. >> >> However, the list of VPS providers who are willing to *support* OpenBSD is >> extremely small > > > Yes, this is true. http://www.bsws.de/en/ http://www.bsws.de/en/sicherheit/ It is based on OpenBSD, if someone is interested. BS actively supports the development of OpenBSD (yup developers). Maybe it's worth to publish on openbsd.org a list of companies with such an offer (OpenBSD based VPS)? btw. I do not have nothing to do with them, provides a link only. Best regards, Daniel
Re: Too much SUID/SGID files!
2015-01-06 8:27 GMT+01:00 whoami toask : > Hello, > > isn't there too much SUID/SGID files on a default OpenBSD install? No. I think you don't understand how SGID works. A small example: 155910 84 -r-xr-sr-x4 root crontab 41752 Aug 8 08:06 /usr/bin/at/usr/bin/at If you run 'at' as a non-root user, then you do it as a user + crontab group, so the 'at' isn't executed with _root_ privileges. > Can this number be reduced? No. > # find / -perm -4000 -o -perm -2000 -ls -print | wc -l > 32 Ok, now clean the list from non-root SGID and give the result. btw. please don't cross-post (misc+tech). > Thanks, > > have a secure day! You too, Daniel
pax: directory traversal (from CVE request)
http://www.openwall.com/lists/oss-security/2015/01/07/5 Does someone can confirm this vulnerability? It's probably the problem of "OpenBSD-derived (?) pax". Best regards, Daniel
Report of an NSA Employee about a Backdoor in the OpenSSH Daemon [pdf] (spiegel.de)
http://www.spiegel.de/media/media-35663.pdf "PANT SPARTY is a backdoor in the SSH daemon for *NIX, based on OpenSSH portable" +local copy (pdf). Daniel [demime 1.01d removed an attachment of type application/pdf which had a name of media-35663.pdf]
Re: crowding out bsd using systemd?
2014-06-29 1:05 GMT+02:00 ian kremlin : >> that bsd is being crowded out, a thought that had not crossed my mind. >> I wanted to know, before assuming that it is the case everywhere, do >> people really not like systemd and is it really hurting bsd? If so, >> I'd be interested in doing something about it. Thanks, David > > yes, systemd has become a very polarizing subject due to its > unportability (as it's written in pure C) and the mindset and actions of > its authors. it is much, much more than an init daemon and while its > prevalence has served to hurt other systems in the short-term, I > guarantee you will we work around it and do systemd's job properly and > safely just as (we) have done with other software in the past. i am not > a long-term OpenBSD contributor and am admittedly a fledgling > programmer, but from what I've witnessed much of the > systemd/anti-systemd debate is rife with needless animosity and ego. systemd is very invasive and destroys all that different. That's why people are angry. http://ewontfix.com/14/ http://ewontfix.com/15/ by Rich Felker (musl libc). >> That said there is a GSOC project underway as we type to bring a much >> slimmed down systemd look-alike functionality to OpenBSD to allow more >> not-well written software to be ported. > > that's me :) > soon, (by the end of gsoc) we will have perfect implementations of https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systemd-utl.git;a=blob;f=scripts/gen-gdbus-interfaces.sh;h=f827434d0211ea8765c075fdb2916386ffc16ecb;hb=HEAD btw. it's bashism in a posix shell suit? Daniel > hostnamed, localed, and timedated as well as a framework for porting the > logind behemoth. you can follow the progress at > https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systemd-utl.git > > ian
Re: crowding out bsd using systemd?
2014-06-29 13:40 GMT+02:00 Antoine Jacoutot : > So first you comment on Ian's GSoC and now on systemd... thai is confusing. > I don't care about systemd we will never have it. We just need some > interfaces > that are currently only implemented in systemd. This is the right approach to the subject: we need only some interfaces from systemd. Nothing more.
Re: LibreSSL & Post-Quantum World, NTRU
2014-09-13 19:27 GMT+02:00 why not : > hello > > Besides NTRU is having a GPL licence, https://github.com/NTRUOpenSourceProject/ntru-crypto/issues/4 https://github.com/tbuktu/libntru but: http://blog.cr.yp.to/20140213-ideal.html Daniel
Re: Safe C
http://cyclone.thelanguage.org/ http://en.wikipedia.org/wiki/Cyclone_(programming_language) http://trevorjim.com/papers/usenix2002.pdf http://homes.cs.washington.edu/~djg/papers/cyclone-cuj.pdf Best regards, Daniel
Re: Where is the 'tar' source code?
ln /bin/pax /bin/tar?
Re: FreeBSD's Capsicum
2014-11-02 16:49 GMT+01:00 : > Hi, > > From what I gather, RBAC / MAC isn't really necessary unless you add people > to your system that you don't really trust (ref. Nick Holland @ > http://marc.info/?l=openbsd-misc&m=139321387226212). But what about FreeBSD's > Capsicum? http://www.openbsdfoundation.org/gsoc2014.html Daniel
Re: Request for Funding our Electricity
http://goteo.org/project/gnupg-new-website-and-infrastructure Why do not you do such a campaign? Wow.. new website and infrastructure for GnuPG. Result: more then 24k USD in three weeks. So where OpenBSD/OpenSSH are worse than GnuPG? Guys, your problem is not the OpenBSD foundation, but the total lack of good marketing. Best regards, Daniel
Re: Request for Funding our Electricity
2014/1/16 Jack Woehr : > Daniel Cegiełka wrote: >> >> http://goteo.org/project/gnupg-new-website-and-infrastructure >> >> Why do not you do such a campaign? > > > I think Theo has answered this previously. His point was that he doesn't > want to spend his time year after year > running campaigns. Being neither a politician nor a diplomat nor a > grantmaster, he wants a sustainable model. I agree that in the long term stable funding is needed. Today, however, we are faced with shut down risk. Another example: Google will pay even more than $3000 for finding an error in OpenSSH (Core infrastructure network services) - do they know about your problems? http://googleonlinesecurity.blogspot.com/2013/10/going-beyond-vulnerability-rewards.html Daniel
Re: Is [binary] package signing planned?
2014-02-04 Kim Twain : > Does pkg_add automatically check these signatures, or, as of now, I'd need > to manually download the packages, verify them with signify and then install > them locally with pkg_add? from man pkg: If a package is digitally signed: o pkg_add checks that its packing-list is not corrupted and matches the cryptographic signature stored within. o pkg_add verifies that the signature was emitted by a valid user certificate, signed by one of the authorities in /etc/ssl/pkgca.pem o pkg_add verifies that each file matches its sha256 checksum right after extraction, before doing anything with it. o pkg_add verifies that any dangerous mode or owner is registered in the packing-list. more: http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_add&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Daniel
Re: Is [binary] package signing planned?
2014-02-04 Otto Moerbeek : > On Tue, Feb 04, 2014 at 03:41:09PM +0100, Daniel Cegie?ka wrote: > > I believe that in -current, the pubkey comes from /etc/signify. > > -Otto yes, but man pkg_sign: -s signify|x509 [-s cert] -s privkey Specify signature parameters for signed packages. Option parameters are as follows: signify|x509choose signify(1) or X.509-style signatures. certthe path to the signer's certificate (X.509 only) privkey the path to the signer's private key. For signify, the private key name is used to set the @signer annotation. If a corresponding public key is found, the first signatures will be checked for key mismatches. For X.509, the signer's certificate and the signer's private key should be generated using standard openssl x509 commands. This assumes the existence of a certificate authority (or several), whose public information is recorded as a /etc/ssl/pkgca.pem file. http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_sign&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html I like signify, it is simple, small and secure (Ed25519). Best, Daniel
Re: Is [binary] package signing planned?
2014-02-04 Marc Espie : > signify(1) makes things more transparent: no chain of trust, pure keys. > > One cool thing is that the signatures are small enough that they can be > embedded directly in the package (which already has sha256 for everything). > > This has the advantage of decentralization: package snapshots can be partially > synchronized, and still each package carries its own signature. Less margin > for strange errors -> stuff that works most of the time -> more trustworthy. wow!? really? And how can I be sure that the public key that I downloaded is exactly the same public key, which is stored on OpenBSD servers (MITM)? signify is a step in the right direction but does not fix anything. We need trusted key distribution (or verification) for signify - without it we will being stuck on the same shit (but successfully verified). best regards, Daniel
Re: Is [binary] package signing planned?
I agree with the fact that we have no solution to this problem, and probably will not find it quickly (or ever). I do not want to shout that now we have to do something. I want to make people aware that even with signify still need to keep limited trust. best, Daniel
Re: OpenBSD rootkits
try this:
--- cat id0.c ---
int getuid(){return 0;}
int geteuid(){return 0;}
int getgid(){return 0;}
int getegid(){return 0;}
--- end cut ---
# shell (as normal user):
id -un
cc -shared id0.c -o id0
LD_PRELOAD=./id0 sh
id -un
best,
Daniel
2014-02-16 22:36 GMT+01:00 :
> Hello!
>
> Came across this on Hacker News earlier today:
>
> New Linux userland rootkit with anti-debugging, new backdoors and
> pcap hiding
>
> https://news.ycombinator.com/item?id=7246836
>
> And it made me wonder -- how vulnerable is OpenBSD to this type of
> stuff?
>
> Thanks!
>
> O.D.
Re: OpenBSD rootkits
2014-02-17 13:15 GMT+01:00 :
> On 16. februar 2014 at 10:11 PM, "Daniel Cegiełka"
> wrote:
>
> try this:
>
> --- cat id0.c ---
> int getuid(){return 0;}
> int geteuid(){return 0;}
> int getgid(){return 0;}
> int getegid(){return 0;}
> --- end cut ---
>
> # shell (as normal user):
> id -un
> cc -shared id0.c -o id0
> LD_PRELOAD=./id0 sh
> id -un
>
>
> What does that do?
>
> O.D.
Nothing (it's safe to self-test, so have fun). id (or whoami) think
that calls functions from libc, but it really calls functions that are
loaded by LD_PRELOAD. These fake functions return 0, so id (whoami)
think that you are root. Attacks with LD_PRELOAD are very old and can
be performed on any OS where you have dynamic linking (Linux, *BSD
etc.), so yes, OpenBSD is "vulnerable" to this type of stuff.
The real attack can be done by loading e.g. fake readpassphrase() function.
http://www.openbsd.org/cgi-bin/man.cgi?query=readpassphrase&sektion=3
readpassphrase() is used e.g. in /usr/libexec/auth/login_* stuff,
signify, ssh, ssh-keygen, ssh-agent, nc, ftp etc. Each of these
programs are dynamically linked, so are LD_PRELOAD sensitive. If an
attacker __can__ LD_PRELOAD false readpassphrase(), will e.g. be able
to get to know your password.
Solution: static linking of critical binaries.
I hope that my explanation was helpful.
best regards,
Daniel
Re: OpenBSD rootkits
2014-02-17 15:49 GMT+01:00 Giancarlo Razzolini : >> Solution: static linking of critical binaries. >> >> I hope that my explanation was helpful. >> >> best regards, >> Daniel >> > Static linking does solves the issue with this particular rootkit, but > won't help with kmod rootkits. The truth is that there is no bullet > proof in any case, if your machine was compromised, you should assume > that it has some form of rootkit and should proceed with the full > re-installation of the OS. And you should scan very throughly your > backups to assure that they won't reinstall the rootkit. I'm not even > mentioning other forms of rootkits that are OS agnostic, such as BIOS, > MBR, etc. There are even HDD controller's backdoors these days: > http://spritesmods.com/?art=hddhack. briefly: that's right, but we're talking (only) about the vulnerabilities associated with LD_PRELOAD. Daniel > Cheers, > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC
Re: OpenBSD rootkits
2014-02-16 23:36 GMT+01:00 Frank Brodbeck : > I am not sure what point it is you are trying to make but: > > $ LD_PRELOAD=./id0 sh > \u@\h:\w\n$ id -un > root > \u@\h:\w\n$ less /etc/master.passwd > /etc/master.passwd: Permission denied > \u@\h:\w\n$ ls -l /etc/master.passwd > -rw--- 1 root wheel 3984 Feb 5 22:44 /etc/master.passwd > \u@\h:\w\n$ again: --- Nothing (it's safe to self-test, so have fun). id (or whoami) think that calls functions from libc, but it really calls functions that are loaded by LD_PRELOAD. These fake functions return 0, so id (whoami) think that you are root. --- This means that you don't have root access (or uid 0), but id (whoami) think that you are root (uid 0). If you put something more dangerous in a function such as readpassphrase(), you can e.g. capture the passwords etc. This example shows that using LD_PRELOAD you can inject your own code on OpenBSD. I hope that now it is more understandable. Daniel
Re: OpenBSD rootkits
And it never was a threat? http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0872 http://www.cvedetails.com/cve/CVE-2006-6164/ Daniel
Re: OpenBSD rootkits
2014-02-17 20:48 GMT+01:00 Miod Vallat :
>> Attacks with LD_PRELOAD are very old and can
>> be performed on any OS where you have dynamic linking (Linux, *BSD
>> etc.), so yes, OpenBSD is "vulnerable" to this type of stuff.
>
> You forgot to mention that the value of LD_PRELOAD is ignored for set*id
> executables, in order to prevent these kind of games.
thx, I wasn't sure of this, but it's good to hear that.
http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/loader.c?rev=1.147;content-type=text%2Fplain
from loader.c
/*
* Don't allow someone to change the search paths if he runs
* a suid program without credentials high enough.
*/
_dl_trust = !_dl_issetugid();
if (!_dl_trust) { /* Zap paths if s[ug]id... */
if (_dl_libpath) {
_dl_free_path(_dl_libpath);
_dl_libpath = NULL;
_dl_unsetenv("LD_LIBRARY_PATH", envp);
}
if (_dl_preload) {
_dl_preload = NULL;
_dl_unsetenv("LD_PRELOAD", envp);
}
It actually should reduce the risk for set*id(), but this in the past
related to CVE-2006-6164 (_dl_unsetenv())?
Daniel
>
> Miod
Re: OpenBSD rootkits
2014-02-17 21:25 GMT+01:00 Theo de Raadt :
>>2014-02-17 20:48 GMT+01:00 Miod Vallat :
Attacks with LD_PRELOAD are very old and can
be performed on any OS where you have dynamic linking (Linux, *BSD
etc.), so yes, OpenBSD is "vulnerable" to this type of stuff.
>>>
>>> You forgot to mention that the value of LD_PRELOAD is ignored for set*id
>>> executables, in order to prevent these kind of games.
>>
>>thx, I wasn't sure of this, but it's good to hear that.
>>
>>http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/loader.c?rev=1.147;content-type=text%2Fplain
>>
>>from loader.c
>>
>>/*
>>* Don't allow someone to change the search paths if he runs
>>* a suid program without credentials high enough.
>>*/
>>_dl_trust = !_dl_issetugid();
>>if (!_dl_trust) { /* Zap paths if s[ug]id... */
>>if (_dl_libpath) {
>>_dl_free_path(_dl_libpath);
>>_dl_libpath = NULL;
>>_dl_unsetenv("LD_LIBRARY_PATH", envp);
>>}
>>if (_dl_preload) {
>>_dl_preload = NULL;
>>_dl_unsetenv("LD_PRELOAD", envp);
>>}
>>
>>It actually should reduce the risk for set*id(), but this in the past
>>related to CVE-2006-6164 (_dl_unsetenv())?
>>
>>Daniel
>
> Daniel, you are coming off like a KOOK.
>
> So basically, we are "vulnerable", even though the shared library linker
> code has been doing this since before we switched over to using it, from
> before a.out.
>
> Apparently the "magic quotes" around "vulnerable" are designed to make
> it so that you can get away with lying. We are not vulnerable. You are
> spreading misinformation. This is beyond misinforming, you are LYING.
Theo, thank you for the clarification. I think it's worth finish this
and admitting you're right.
Daniel
Re: OpenBSD rootkits
2014-02-17 21:49 GMT+01:00 Marc Espie : > On Mon, Feb 17, 2014 at 07:48:44PM +, Miod Vallat wrote: >> > Attacks with LD_PRELOAD are very old and can >> > be performed on any OS where you have dynamic linking (Linux, *BSD >> > etc.), so yes, OpenBSD is "vulnerable" to this type of stuff. >> >> You forgot to mention that the value of LD_PRELOAD is ignored for set*id >> executables, in order to prevent these kind of games. >> >> Miod > > Last time I've seen abuse of LD_PRELOAD was with the "on" binary on > SunOS. Of course, that predated any kind of security, as on was > a stupid RPC program without any kind of setuid that simply "trusted" > getuid() on the client host. > > That was a bit like shooting fish in the barrel, it was about the same > time NFS earned its true name (Notreally a File System)... > > To put things in perspective, that was roughly 20 years ago. At least on linux this type of abuse seem to be still (very) effective: http://blackhatlibrary.net/LD_PRELOAD http://blackhatlibrary.net/Azazel and of course PAM: http://blackhatlibrary.net/Hooking_PAM Daniel
Re: OpenBSD rootkits
2014-02-17 22:12 GMT+01:00 Miod Vallat : >> and of course PAM: >> >> http://blackhatlibrary.net/Hooking_PAM > > Well, there's a reason why OpenBSD does not embed PAM. It has to do with > software giving people enough rope to hang themselves. PAM its just API. You can write small and simple pam_bsdauth module and call stuff in /usr/libexec/auth/ in BSD Auth style, so you can get privilege separation etc. but another issue is the simplicity of solutions and space to attack, and especially Linux-PAM (vs OpenPAM) is terribly overblown.
Re: OpenBSD rootkits
2014-02-17 20:20 GMT+01:00 Theo de Raadt : Theo, I think went wrong with this topic. Firstly, I don't know of any vulnerability in order to gain privilege (e.g. uid 0) using LD_PRELOAD. I want it to be clearly defined. And yes, shown trick with LD_PRELOAD was cheap and didn't give any root rights etc. Despite this, "id" (or user) was tricked and thought that is the root (some even tried to read the /etc/master.passwd). > The above is no different from copying the "id" binary to a new place, > then hand-editing the binary to return 0 deep inside it, then running > this new copy. Whoohoo! Terrible risk! Modified code lied to me! Yes, but if you do that, the modified or hand-edited binary can be easily detected (hash sum) and analyzed. This means that it isn't the best way to hide a backdoor. Is that correct? So I have a question. If you already have root privileges and you want to run a backdoor and you want to make it difficult to detect (held only in memory - without modifying binary files), can you do so on OpenBSD by using LD_PRELOAD? Best regards, Daniel
Re: OpenBSD rootkits
Hi Giancarlo,
Maybe I'm totally wrong here:
2014-02-17 20:20 GMT+01:00 Theo de Raadt :
>>2014-02-16 23:36 GMT+01:00 Frank Brodbeck :
>>> I am not sure what point it is you are trying to make but:
>>>
>>> $ LD_PRELOAD=./id0 sh
>>> \u@\h:\w\n$ id -un
>>> root
>>> \u@\h:\w\n$ less /etc/master.passwd
>>> /etc/master.passwd: Permission denied
>>> \u@\h:\w\n$ ls -l /etc/master.passwd
>>> -rw--- 1 root wheel 3984 Feb 5 22:44 /etc/master.passwd
>>> \u@\h:\w\n$
>>
>>again:
>>
>>---
>>Nothing (it's safe to self-test, so have fun). id (or whoami) think
>>that calls functions from libc, but it really calls functions that are
>>loaded by LD_PRELOAD. These fake functions return 0, so id (whoami)
>>think that you are root.
>>---
>>
>>This means that you don't have root access (or uid 0), but id (whoami)
>>think that you are root (uid 0). If you put something more dangerous
>>in a function such as readpassphrase(), you can e.g. capture the
>>passwords etc. This example shows that using LD_PRELOAD you can inject
>>your own code on OpenBSD.
>>
>>I hope that now it is more understandable.
>
> This is a complete joke; you are failing to explain it properly to
> people.
>
> The above is no different from copying the "id" binary to a new place,
> then hand-editing the binary to return 0 deep inside it, then running
> this new copy. Whoohoo! Terrible risk! Modified code lied to me!
>
> There is no risk such as readpassphrase(). You are running the code
> you intend to, and noone has fooled anyone.
yes, it is not possible to pledge a trap for user using LD_PRELOAD.
hmm... definitely I'm wrong!
but I have another example:
--- cat fake.c ---
#define print(s) write(1, (s), sizeof(s) - 1)
int getuid() {
return 32767;
}
int geteuid() {
print("hello from fake geteuid()!\n");
print("you're ");
return 32767;
}
--- end cat ---
# shell (as normal user):
cc -shared fake.c -o fake
LD_PRELOAD=./fake ksh
and type: whoami
As you can see, this is not possible to inject any code in "whoami".
So we can sleep well. It doesn't work on OpenBSD ;]
Stay secure,
Daniel
Re: OpenBSD rootkits
2014-02-18 18:42 GMT+01:00 Giancarlo Razzolini : > Em 18-02-2014 14:36, Dmitrij D. Czarkoff escreveu: >> You perfectly demonstrated your ability to alter the code that will be >> run with your privileges. Still, it is useless as the injected code >> will be running with your privileges, so this has no practical output. >> Either you are able to demonstrate the way you raise your privileges >> using this method or you failed to make your point. > Dmitri, > > We are not discussing privilege escalation. We assume that for > installing a rootkit, one has root access on the machine. Hence the root > in rootkit. What we are discussing is if it is possible, using > LD_PRELOAD, to inject code on the execution of any given programs, and > to be able to hide the fact that the machine has a rootkit installed > using this method. > > Cheers, > Giancarlo Razzolini > GPG: 4096R/77B981BC > yup, and as I wrote earlier: Firstly, I don't know of any vulnerability in order to gain privilege (e.g. uid 0) using LD_PRELOAD. I want it to be clearly defined. http://osdir.com/ml/general/2014-02/msg33581.html Daniel
Re: OpenBSD rootkits
2014-02-18 20:10 GMT+01:00 Dmitrij D. Czarkoff : > Giancarlo Razzolini said: >> ... What we are discussing is if it is possible, using >> LD_PRELOAD, to inject code on the execution of any given programs, and >> to be able to hide the fact that the machine has a rootkit installed >> using this method. > > So you think that placing rootkit in LD_PRELOAD hides it? I would wonder > about your definition of revealing then. No, this can't be so easily hidden. You can compare used syscalls with addresses directly from libc.so (path) using dlsym() and RTLD_NEXT, but this crazy method of checking. The easiest way to prevent LD_PRELOAD hooks is static linking.
Re: OpenBSD rootkits
2014-02-19 3:32 GMT+01:00 Theo de Raadt :
>>2014-02-17 22:12 GMT+01:00 Miod Vallat :
and of course PAM:
http://blackhatlibrary.net/Hooking_PAM
>>>
>>> Well, there's a reason why OpenBSD does not embed PAM. It has to do with
>>> software giving people enough rope to hang themselves.
>>
>>PAM its just API. You can write small and simple pam_bsdauth module
>>and call stuff in /usr/libexec/auth/ in BSD Auth style, so you can get
>>privilege separation etc. but another issue is the simplicity of
>>solutions and space to attack, and especially Linux-PAM (vs OpenPAM)
>>is terribly overblown.
>
> Bullshit.
>
> PAM uses shared library loading to pull (specified shared library) code into
> a program, to do the authentication. You have to trust that shared library
> code.
>
> But BSD auth does not do that! It does not require you to pull someone
> else's crap code into your binary!
>
> Saying "it is just API" makes it clear you are not a programmer.
Theo, as a great programmer can you explain to us all what does this
piece of code? from L351:
https://github.com/freebsd/freebsd/blob/master/contrib/openpam/include/security/openpam.h#L358
/*
* Infrastructure for static modules using GCC linker sets.
* You are not expected to understand this.
*/
#if !defined(PAM_SOEXT)
# define PAM_SOEXT ".so"
#endif
#if defined(OPENPAM_STATIC_MODULES)
# if !defined(__GNUC__)
# error "Don't know how to build static modules on non-GNU compilers"
# endif
/* gcc, static linking */
# include
# include
# define PAM_EXTERN static
# define PAM_MODULE_ENTRY(name) \
static char _pam_name[] = name PAM_SOEXT; \
static struct pam_module _pam_module = { \
.path = _pam_name, \
.func = { \
[PAM_SM_AUTHENTICATE] = _PAM_SM_AUTHENTICATE, \
[PAM_SM_SETCRED] = _PAM_SM_SETCRED, \
[PAM_SM_ACCT_MGMT] = _PAM_SM_ACCT_MGMT, \
[PAM_SM_OPEN_SESSION] = _PAM_SM_OPEN_SESSION, \
[PAM_SM_CLOSE_SESSION] = _PAM_SM_CLOSE_SESSION, \
[PAM_SM_CHAUTHTOK] = _PAM_SM_CHAUTHTOK \
}, \
}; \
DATA_SET(_openpam_static_modules, _pam_module)
It's terrible, because openssl uses engines, it also is not possible
to statically compile binaries. Right?
