Network Security - Monolithic or Modular? - Security

This is a discussion on Network Security - Monolithic or Modular? - Security ; Hello Linux Greybeards, I am interested in your input on the issue of which of the following makes for better network security under Linux. a) compile everything you need into the kernel proper, eliminating any module loading. Please confirm that ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Network Security - Monolithic or Modular?

  1. Network Security - Monolithic or Modular?

    Hello Linux Greybeards,

    I am interested in your input on the issue of which of the following makes
    for better network security under Linux.

    a) compile everything you need into the kernel proper, eliminating any
    module loading. Please confirm that it is possible to completely turn off
    module loading in the kernel.

    b) compile as little as possible into the kernel proper, with most
    functionality provided by loadable modules.

    From my reading, the second alternative allows for better tunability since
    you can unload and reload the modules (perhaps with different parameters)
    without having to reboot. Apparently there is room for an
    unauthorized module to get loaded though. How would that be prevented?
    On the other hand, even if everything is contained inside the kernel, it
    is still possible to alter the behavior of the running kernel on the fly
    by writing to /proc. Is that absolutely necessary for linux to run
    properly and if not, how is a rogue process prevented from doing it?

    Assuming the objective is to maximize network security, which is the better
    approach and why? It seems as if either alternative is possible these
    days when a gigabyte of memory costs a hundred dollars, so which is best?

  2. Re: Network Security - Monolithic or Modular?

    John wrote:

    >
    > I am interested in your input on the issue of which of the following makes
    > for better network security under Linux.
    >
    > a) compile everything you need into the kernel proper, eliminating any
    > module loading. Please confirm that it is possible to completely turn off
    > module loading in the kernel.
    >
    > b) compile as little as possible into the kernel proper, with most
    > functionality provided by loadable modules.
    >
    > From my reading, the second alternative allows for better tunability since
    > you can unload and reload the modules (perhaps with different parameters)
    > without having to reboot. Apparently there is room for an
    > unauthorized module to get loaded though. How would that be prevented?
    > On the other hand, even if everything is contained inside the kernel, it
    > is still possible to alter the behavior of the running kernel on the fly
    > by writing to /proc. Is that absolutely necessary for linux to run
    > properly and if not, how is a rogue process prevented from doing it?
    >


    Dumb speculative question.

    There is big long list of questions one should be asking to decide how
    secure one's system is. This is way near the bottom and the answer really
    depends on the previous answers. You've also omitted a possible answer
    which will often be the the 'right' one i.e.

    c) don't mess about with things with things the support staff don't fully
    understand.

    But assuming that you are justified in trying to differentiate between a & b
    - AFAIK there is no planned way to insert code into a running kernel via
    the proc interface. But that's no excuse not to be hardening your system,
    scanning for rootkits, running IDS and anti-sniff etc.

    C.


  3. Re: Network Security - Monolithic or Modular?

    John sez:
    > Hello Linux Greybeards,
    >
    > I am interested in your input on the issue of which of the following makes
    > for better network security under Linux.
    >
    > a) compile everything you need into the kernel proper, eliminating any
    > module loading. Please confirm that it is possible to completely turn off
    > module loading in the kernel.
    >
    > b) compile as little as possible into the kernel proper, with most
    > functionality provided by loadable modules.

    ....
    > Assuming the objective is to maximize network security, which is the better
    > approach and why?


    Irrelevant: if an evil hacker can get to the kernel, your network
    security's already been r0073d beyond repair.

    Dima
    --
    Yes, Java is so bulletproofed that to a C programmer it feels like being in a
    straightjacket, but it's a really comfy and warm straightjacket, and the world
    would be a safer place if everyone was straightjacketed most of the time.
    -- Mark 'Kamikaze' Hughes

  4. Re: Network Security - Monolithic or Modular?

    John (06-03-29 16:20:18):

    > I am interested in your input on the issue of which of the following
    > makes for better network security under Linux.
    >
    > a) compile everything you need into the kernel proper, eliminating any
    > module loading. Please confirm that it is possible to completely turn
    > off module loading in the kernel.
    >
    > b) compile as little as possible into the kernel proper, with most
    > functionality provided by loadable modules.
    >
    > From my reading, the second alternative allows for better tunability
    > since you can unload and reload the modules (perhaps with different
    > parameters) without having to reboot. Apparently there is room for an
    > unauthorized module to get loaded though. How would that be
    > prevented? On the other hand, even if everything is contained inside
    > the kernel, it is still possible to alter the behavior of the running
    > kernel on the fly by writing to /proc. Is that absolutely necessary
    > for linux to run properly and if not, how is a rogue process prevented
    > from doing it?
    >
    > Assuming the objective is to maximize network security, which is the
    > better approach and why? It seems as if either alternative is
    > possible these days when a gigabyte of memory costs a hundred dollars,
    > so which is best?


    This question cannot be answered right away, and it is not related to
    security. There are a lot of things to consider, before you can make
    that decision. Firstly, what kind of host is it? If it is a
    workstation, then you are not going to turn off module loading anyway,
    because many third party drivers come as kernel modules.

    If you are that afraid of kernel module loading, but you cannot turn it
    off, then you can harden your system with SELinux or grsecurity.
    Personally I use the latter one (but not because of module loading).
    They have in common that you can destroy the possibility to load modules
    as root. So you add some kind of user, which is 'above root', and the
    root user becomes less privileged.

    Now to the /proc interface, and as of Linux 2.6, also to the /sys
    interface. Important configuration options can be changed there, and
    many system informations can be read. This is the intention of those
    interfaces, so it is not a threat by itself. Nobody could harm your
    system via /proc or /sys as a normal user. By using one of the two
    packages mentioned above, you can restrict write access (and also read
    access) to those pseudo-filesystems. E.g. on my system, only root can
    read /proc/sys. Normal users can't even read it.

    To secure your system, all you have to do is to prevent privilege
    escalation (this includes not only system privileges, but also network
    privileges). So normal users must not have the possibility to become
    root, or read network traffic not intended for them. If this is the
    case, then you don't even need the security packages, and you don't have
    to worry about /proc or /sys.

    Short: Configure your system properly, so it doesn't matter whether you
    allow module loading or not, or how much read access normal users have
    to /proc and /sys. Securing your system by disclosing system
    informations is security by obscurity. And 'securing' your system by
    restricting the root user is even worse.


    Regards.

  5. Re: Network Security - Monolithic or Modular?

    On Thu, 30 Mar 2006 12:09:52 +0200, Ertugrul Soeylemez wrote:

    > John (06-03-29 16:20:18):
    >
    >> I am interested in your input on the issue of which of the following
    >> makes for better network security under Linux.
    >>
    >> a) compile everything you need into the kernel proper, eliminating any
    >> module loading. Please confirm that it is possible to completely turn
    >> off module loading in the kernel.
    >>
    >> b) compile as little as possible into the kernel proper, with most
    >> functionality provided by loadable modules.
    >>

    (snipped)
    >
    > This question cannot be answered right away, and it is not related to
    > security. There are a lot of things to consider, before you can make
    > that decision. Firstly, what kind of host is it? If it is a
    > workstation, then you are not going to turn off module loading anyway,
    > because many third party drivers come as kernel modules.


    My system is a standalone workstation, connected to the internet. I
    have no servers running on public interfaces. I also do not have local
    security issues since I am the only user. I do make backups and store
    them offsite for files I don't want to lose.

    I'm not building missiles here, just curious about security.

    I've read that *most* or *many* rootkits use the loadable kernel mechanism
    to "install". If this happens as a result of a buffer overflow
    vulnerability in a program used to access the internet eg a web browser
    then it is a fundamental risk that depends on things outside of my
    control. To do my best against that risk I will watch security reports.
    If it happens as a result of some system weakness that I can control
    then I want to find out what weakness that is.

    I'd like to read your "short list" of things to do to prevent
    privilege escalation. I'm going to start by eliminating as many "suid"
    permissions as possible and by eliminating the ability for normal users to
    execute "su" and "sudo". What else do you suggest? Set permissions on
    certain executables to 700?

    Thanks for your (positive and useful) post. Your comments about
    preventing privelege escalation have focussed my thinking on that as the
    fundamental issue - assuming of course that the basic permissions on the
    system are sound. It should be possible to access the internet without
    getting a "root kit" or "key logger" installed (in the absence of an
    unknown buffer overflow vulnerability). That's the risk that I'm trying
    to reduce.

    Thanks again.

  6. Re: Network Security - Monolithic or Modular?

    John (06-03-30 17:14:54):

    > > This question cannot be answered right away, and it is not related
    > > to security. There are a lot of things to consider, before you can
    > > make that decision. Firstly, what kind of host is it? If it is a
    > > workstation, then you are not going to turn off module loading
    > > anyway, because many third party drivers come as kernel modules.

    >
    > My system is a standalone workstation, connected to the internet. I
    > have no servers running on public interfaces. I also do not have local
    > security issues since I am the only user. I do make backups and store
    > them offsite for files I don't want to lose.


    This already opens a few holes, if you are as paranoid as I am. Your
    backups are offsite. Are they encrypted? If yes, are you using proper
    encryption methods and a strong key? If not, then this is already a
    security hazard. Anybody could get their hands on your data. Now
    imagine your hard disk crashes and you have to switch to the backup.
    Somebody could have modified it. In any case, you are going to encrypt
    at least your home directory or the whole /home tree (as I do). As long
    as /home has its own partition, this is very easy to setup.

    There is always the risk of your password being intercepted (by your
    'best friend', when he sits besides you, for example). There are ways
    to defend against this, but they come with other problems. You might
    want to use key-based authentication. Save your key on a USB stick or
    floppy and use it to login. The key itself should be encrypted as well.
    However, I would not do this. It may well be the case that the disk
    gets lost or becomes unreadable, effectively locking you out of your own
    system. It's far better to just make sure that nobody looks over your
    shoulder when typing your password. However, of course there are
    keyboard wiretaps. You can't defend against any possible security
    problem.


    > I'm not building missiles here, just curious about security.


    Yes, and you are certainly not doing wrong being concerned about
    security. In fact, it's just my privacy I want to protect. Sure, the
    government is not going to be interested in my data. But if I make sure
    even they can't get to it, then I'm also secured against my 'best
    friend'.


    > I've read that *most* or *many* rootkits use the loadable kernel
    > mechanism to "install". If this happens as a result of a buffer
    > overflow vulnerability in a program used to access the internet eg a
    > web browser then it is a fundamental risk that depends on things
    > outside of my control. To do my best against that risk I will watch
    > security reports. If it happens as a result of some system weakness
    > that I can control then I want to find out what weakness that is.


    Rootkits use kernel modules and a bunch of other things to hide their
    presence. They still give an attacker access without kernel modules.
    So preventing kernel module loading is no gain in security, it just
    makes online rootkit detection easier. If anyone gets to root access to
    your system, then it's lost anyway. As already said, better don't rely
    on security by obscurity.


    > I'd like to read your "short list" of things to do to prevent
    > privilege escalation. I'm going to start by eliminating as many
    > "suid" permissions as possible and by eliminating the ability for
    > normal users to execute "su" and "sudo". What else do you suggest?
    > Set permissions on certain executables to 700?


    Depends. By eliminating SUID permissions you theoretically don't gain
    any security, because SUID programs are (or should be) written properly
    to not allow normal users to do things they are not supposed to do.
    Most SUID programs drop their enhanced privileges after initialization.
    Personally I don't do this.

    Setting executables' permissions to 700 is also no gain in security. I
    assume you are meaning non-SUID programs here. They are going to be
    executed with the user's (reduced) privileges anyway. It's not only
    useless, it even makes things more difficult. I don't do this either.

    Allow 'su' only for persons, who are intended to become other users
    (including root). In your case, this is only you. Allow the same group
    of users full 'sudo' access, but with proper authentication mechanisms.
    If you use password authentication for your root account, then sudone
    commands should require the same. To make things more comfortable, sudo
    can be configured to remember the login, so you don't have to type the
    password each time again.

    Now to the 'short list'. You can express it with a single sentence:
    Don't be stupid. To be more verbose, ...
    * don't run services you don't use
    * don't do things you don't understand
    * configure every service you use by hand; don't rely on the default
    configuration
    * read the FAQs and manuals; they have good reasons to be
    * if you give remote access to other users, make sure they don't get
    to your data, i.e. set proper permissions on $HOME
    * don't rely on local laws
    * better keep also privacy in mind, instead of only system security,
    because you cannot prevent your system from being compromised
    physically

    The last item is the most important. When configuring your system,
    always assume the worst case. Assume someone stealing your hard-disk.
    Your system is already compromised then. He can do far more than some
    remote attacker. If even he cannot get to your data, then your system
    is secure.


    > Thanks for your (positive and useful) post. Your comments about
    > preventing privelege escalation have focussed my thinking on that as
    > the fundamental issue - assuming of course that the basic permissions
    > on the system are sound. It should be possible to access the internet
    > without getting a "root kit" or "key logger" installed (in the absence
    > of an unknown buffer overflow vulnerability). That's the risk that
    > I'm trying to reduce.


    There are a few quite different threats, but they are closely related.
    In the workstation case, you are going to defend against:
    * privilege escalation (by proper configuration and secure software)
    * information disclosure (by encryption)
    * identity forging (by authentication)
    * denial of service (by various techniques like filtering)
    * physical problems, i.e. theft or damage (by locking your door)

    For a workstation, in most cases it's enough to use the 'right'
    software, and do frequent backups. This leads to a little decision
    problem, because there is no 'right' program for mail reading. You use
    the 'right' program by not using the 'wrong' program. So again, this is
    not a list of dos, but a list of donts. So ...
    * don't use Sendmail as your MTA (use Postfix or Exim instead; I don't
    use any MTA)
    * don't use Thunderbird as your mail-reader (I use sylpheed-claws)
    * don't use PGP for mail privacy/authenticity (I use GnuPG)

    In fact, you shouldn't even use Firefox, because from time to time
    security flaws are found in it. But I use it, because it's
    full-featured and still faster than most other (full-featured) clients.
    The security flaws are seldom critical. When paranoid, add a second
    user for web browsing and sudo Firefox.


    Regards.

  7. Re: Network Security - Monolithic or Modular?

    Thank you for your post. I think we share the same attitudes but I don't
    think of myself as paranoid. I'm just *highly offended* at the notion of
    unauthorized access to my stuff, which amounts to the same thing.

    The toughest step to put in practice is "don't do things you don't
    understand" so I am going to read a lot.

    Thanks again. If you wrote a book on this subject I would buy it, by the
    way.


  8. Re: Network Security - Monolithic or Modular?

    John (06-03-31 15:18:52):

    > Thank you for your post. I think we share the same attitudes but I
    > don't think of myself as paranoid. I'm just *highly offended* at the
    > notion of unauthorized access to my stuff, which amounts to the same
    > thing.


    I for myself don't think, that this is paranoia, too. Unfortunately
    most other people do. I think, there is a huge difference between
    paranoia and security awareness.


    > Thanks again. If you wrote a book on this subject I would buy it, by
    > the way.


    If I would, then it would be a freely available tutortial anyway. =)


    Regards.

  9. Re: Network Security - Monolithic or Modular?

    On Thu, 30 Mar 2006 17:14:54 +0000, John wrote:

    > I'd like to read your "short list" of things to do to prevent
    > privilege escalation.


    Hope ya'll don't mind me posting to your discussion, but here goes...

    * Put /home, /var and /tmp on a seperate partition and mount: nosuid,nodev
    * Add some users and groups, for your apps to run under.

    If any of those are X11 applications set them up to have desktop access.
    To do that, add them to the same group as the user that starts the
    X server, 'users' in my case, and put the following in excuteable file:
    /etc/profile.d/xauth.sh

    ---------------------------------
    #!/bin/sh

    DISPLAY=unix:0.0
    XAUTHORITY=/tmp/.Xauthority
    export DISPLAY XAUTHORITY
    ----------------------------------

    And in the .xinitrc of the user from which the X server gets started the
    following snipped (although one could put it in the 'startx' script too):

    ------------------------------------
    if [ -z $XAUTHORITY ]; then
    XAUTHORITY=/tmp/.Xauthority
    export XAUTHORITY
    fi

    if [ ! -f $XAUTHORITY ]; then
    if ! /bin/touch $XAUTHORITY ; then
    echo "Error: /bin/touch $XAUTHORITY" >&2
    fi
    fi

    if ! /bin/chmod g+r $XAUTHORITY ; then
    echo "Error: /bin/chmod g+r $XAUTHORITY" >&2
    fi
    ------------------------------------

    * Add groups for suid-bin ownership (please read-on for a script).

    Put only users that need the functionality in those groups.

    * Set TMP and TMPDIR env-vars to dirs only the user can write to.

    On my distro of choise (Slackware) probably put the following in
    /etc/profile.d/tmpdir.sh - and set it executeable ofcource - on other
    distros maybe add it to /etc/profile, or just your ~/.bash{_login,rc}

    ------------------------------------------------
    #!/bin/sh

    if [ ! -d $HOME/tmp -a "$HOME" != "/" ]; then
    rm -rf $HOME/tmp
    mkdir -p $HOME/tmp
    fi

    chown $USER $HOME/tmp
    chmod 0750 $HOME/tmp

    export TMPDIR=$HOME/tmp
    export TMP=$TMPDIR
    ----------------------------------------------------

    * Create a group for X11 DRI and put only the local-desktop user(s) in it.

    In /etc/X11/xorg.conf something like:

    --------------------------------------
    Section "DRI"
    Group "dri"
    Mode 0660
    EndSection
    ---------------------------------------

    groupadd dri
    gpasswd -a menno dri

    > I'm going to start by eliminating as many "suid" permissions as possible
    > and by eliminating the ability for normal users to execute "su" and
    > "sudo".


    I just run 'find / -mount -perm +4000 -ls >std_suid.txt' plus the
    following script, and put 'menno' in some (atleast: 'xorg', 'su',
    'passwd', 'ping' and 'progmail' say) and 'firefox' in none of those.

    ---------------------------------------------------------------------
    #!/bin/sh
    #
    # Search for suid binaries, and put them in thier own groups.
    #
    # * Note we enable read-access allong with execute for the group
    # as this should allow us to do filesystem backups under an abitrary
    # account, provided that it is a member of all groups ...

    if [ -z "$1" ]; then
    echo "Usage: $0 "
    exit 1
    else
    DIR="$1"
    fi

    for f in `find "/$DIR" -mount -type f -perm +4000 -print`; do
    # Convert file names to lowercase and stuff it in F
    F=`echo $f |tr '[A-Z]' '[a-z]'`

    # Create groups if they don't already exist
    if ! grep -q "^`basename $F`:" /etc/group; then
    if ! groupadd `basename $F` ; then
    echo "Error: groupadd `basename $F`" >&2
    fi
    fi

    # See if it's suid
    if [ "`ls -l $f |awk '{print $1}' |cut -c4`" == "s" ]; then
    SUIDEXEC=yes
    else
    SUIDEXEC=no
    fi

    # See if sgid
    if [ "`ls -l $f |awk '{print $1}' |cut -c7`" == "s" ]; then
    SGIDEXEC=yes
    else
    SGIDEXEC=no
    fi

    # Change group ownership to our group
    if ! chgrp `basename $F` $f ; then
    echo "Error: chgrp `basename $F` $f" >&2
    fi

    # Set the file protection bits:
    if [ "$SUIDEXEC" == "yes" -a "$SGIDEXEC" == "yes" ]; then
    # Both SUID and SGID:
    if ! chmod 6750 $f ; then
    echo "Error: chmod 6750 $f" >&2
    fi
    elif [ "$SUIDEXEC" == "yes" ]; then
    # Just SUID:
    if ! chmod 4750 $f ; then
    echo "Error: chmod 4750 $f" >&2
    fi
    else
    echo "Warning: this is odd: `ls -l $f`" >&2
    fi
    done

    ---------------------------------------------------------------------

    Print result:
    find /bin /sbin /usr/bin /usr/sbin -mount -type f -perm +4000 -ls

    (Test it out first and) have fun.
    HTH

    --
    -Menno.


  10. Re: Network Security - Monolithic or Modular?

    On Sat, 01 Apr 2006 18:07:31 +0200, Menno Duursma wrote:

    > On Thu, 30 Mar 2006 17:14:54 +0000, John wrote:
    >
    >> I'd like to read your "short list" of things to do to prevent
    >> privilege escalation.

    >
    > Hope ya'll don't mind me posting to your discussion, but here goes...
    >


    You are welcome, of course. I don't have any comments or questions on
    your suggestions right now but I will go away and study them.

    I will say that X doesn't give me a warm feeling. I would like to be able
    to install just the video configuration aspects on my system and leave out
    all the networking machinery. I think that would fit under the heading of
    "don't install services you don't use". Perhaps that will soon be
    possible - I've read that XOrg is working to break the code into pieces.
    That may offer this opportunity. If so, I will be the first to test it.

    Thanks for your input.


  11. Re: Network Security - Monolithic or Modular?

    "John" wrote in message
    newsan.2006.04.01.16.39.04.215360@somewhere.com

    > I will say that X doesn't give me a warm feeling. I would like to be
    > able to install just the video configuration aspects on my system and
    > leave out all the networking machinery.


    Networking concepts are the very fundamental nature of X.

  12. Re: Network Security - Monolithic or Modular?

    On Sat, 01 Apr 2006 08:46:47 -0800, ynotssor wrote:
    > "John" wrote in message
    > newsan.2006.04.01.16.39.04.215360@somewhere.com
    >
    >> I will say that X doesn't give me a warm feeling. I would like to be
    >> able to install just the video configuration aspects on my system and
    >> leave out all the networking machinery.


    Provided the applications you probably want to use are X11 clients, and
    X11 is a network protocol, there isn't much of a way around running a
    (network) server to use them... You could however have it use only Unix
    domain sockets to connect by starting the server with '-nolisten tcp'
    option.

    BTW: for access control other then the XAUTHORITY file you could instead
    use 'xhost +si:localgroup:users' (maybe put that in ~/.xinitrc then).

    IMO it would be nicer if the umask for crateing /tmp/.X11-unix/X*
    socket(s) could be set (as Linux file-acces could then disallow 'others')
    in like /etc/X11/xorg.conf or some such. The only way i know of to do that
    now would be to edit Xtranssock.c in the Xorg source and recompile i guess.

    > Networking concepts are the very fundamental nature of X.


    Indeed (and that is/hasbeen very useful, atleast to me). There are some
    ports/forks of the Xorg server that might allow for some thighter
    security (or so i read) such as IIUC the OpenBSD one does priv-sep, and
    the XGGI one can run non-root entirely: http://www.ggi-project.org/xggi/
    (I had to edit 'fetch-xorgballs.sh' though, and it took al day to build.)

    --
    -Menno.


  13. Re: Network Security - Monolithic or Modular?

    On Sat, 01 Apr 2006 16:40:03 +0000, John wrote:
    > On Sat, 01 Apr 2006 18:07:31 +0200, Menno Duursma wrote:
    >> On Thu, 30 Mar 2006 17:14:54 +0000, John wrote:
    >>
    >>> I'd like to read your "short list" of things to do to prevent
    >>> privilege escalation.

    >>
    >> Hope ya'll don't mind me posting to your discussion, but here goes...
    >>

    > You are welcome, of course. I don't have any comments or questions on
    > your suggestions right now but I will go away and study them.


    Well i (myself) have. As daemons ofcource sit on a security boundary
    aswell, hence they should be 'secure(ed)'. Most still-maintained network
    service provideing ones can drop privileges, however not all default to
    doing that (take CUPS for example, to get that to work, add "RunAsUser
    yes", "User lp", "Group shadow" (beats be: why it doesn't use initgroups()
    or similar to allow primary group "lp" and secondary "shadow" ...))

    A good idee also maybe to have SSHd, CUPS, etc, listen _only_ on the
    external interface (plus have them use libwrap (tcpwrappers) to boot).

    And for (local) privileage escalation even 'syslogd' (although syslog-ng,
    wich can drop-privs, exists), 'crond', or the like might be exploitable.

    > I will say that X doesn't give me a warm feeling.


    I have not tryed this (yet), but if nothing else; it some major scores
    kewlness points: http://demo.tudos.org/eng_features.html

    (Never mind the papers there to be interesting).

    --
    -Menno.


  14. Re: Network Security - Monolithic or Modular?

    On Fri, 31 Mar 2006 12:46:41 +0200, Ertugrul Soeylemez wrote:
    > John (06-03-30 17:14:54):


    > system. It's far better to just make sure that nobody looks over your
    > shoulder when typing your password. However, of course there are
    > keyboard wiretaps. You can't defend against any possible security
    > problem.


    True, (for instance and atacker could install a PCI bus sniffer (device))
    but you can try, and for instance the new Intel chipsets _do_ in fact try.

    However the one talked about here, _can_ effectively be defended against
    using either hardware tolkens (for one: banks do) or some kind of S/Key
    like one-time-password system.

    A free one maybe the OTP support of KTH/Heimdal Kerberos:
    http://www.pdc.kth.se/heimdal/

    'The' free implementation (defaultly used in *BSD) is OPIE:
    http://www.inner.net/opie

    For which this trivial patch to get it to build here:

    --- opieinfo.c.std 1999-03-11 03:09:53.000000000 +0100
    +++ opieinfo.c 2006-04-02 14:41:56.000000000 +0200
    @@ -40,9 +40,10 @@
    #include
    #endif /* HAVE_PWD_H */
    #include "opie.h"
    +#include

    /* extern char *optarg; */
    -extern int errno, optind;
    +int errno, optind;

    static char *getusername FUNCTION_NOARGS
    {

    An article on how to use:
    http://www.dns-fr.com/~madchat/sysadm/bsd/otpie.html

    And a (some) PAM module(s) for it:
    http://www.kernel.org/pub/linux/libs/pam/modules.html

    --
    -Menno.


+ Reply to Thread