GNOME security




Gnome Experts:

I hope this is the correct mail alias for this discussion, since I notice
there is no security-specific GNOME alias.  I have put together quite a bit
of information about how security works in the GNOME stack and would appreciate
it if anyone could review the document and let me know of any errors, omissions,
or where I fail to dig deep enough in description.  Any pointers to areas in the
code that I should look at more closely would be appreciated.

To keep traffic on the mail alias down, if people respond privately, I will be
happy to update the document and repost it to the list with corrections.  I'm
not sure if there is enough interest, but it might be useful information to
put on the public website or somewhere.

The reason I wrote this document is because Sun's internal ARC (Architecture
Review Committe) requires that we fill out a "Security Questionaire" about
GNOME 2.6 before we can release it for Solaris.  This document tries to
highlight the following:

* That all senstitive data, and all files that control behavior are properly
  protected using reasonable mechanisms (with proper file ownership and
  permssions for example).
* That all processes that interact over potentially insecure channels (such
  as TCP/IP) are highlighted.
* Detailed information about what encryption, magic cookie, entropy, etc.
  technqiues are relied upon to ensure security.
* Highlight programs that might be sensitive to buffer-overflow attacks
  (such as programs that can execute/process data downloaded over the
  network).
* Detail about configurations choices (including non-default) which affect
  security, especially those that reduce the user's security.

Thanks!

Following is the document I've put together so far, based on my research with
the code and discussions I've had with various people:

==========================================
Security Implications With GNOME - DRAFT
by: Brian Cameron  <brian cameron sun com>
last updated: 07/21/2004
Revision: 0.1
==========================================

+ General

  - For a user to use GNOME, he has to have at least read permissions on his
    own files, as well as on his own processes, be able to create files in
    various parts of the system where there's no expectation that a user
    couldn't, etc.

  - GNOME depends on the user's home directory being readable by the user
    because gnome configuration files are stored there.

  - Programs like evolution, mozilla, nautilus, gstreamer, gnome-vfs all can
    access data the user requests from the internet.  Carefully crafted data
    could possibly allow malicious code to execute (such as buffer overrun).
    The same applies to programs launched via mime-type from programs like
    nautilus, mozilla, and evolution (mozilla launching ggv to read a PDF
    document, for example).  In all situations not otherwise highlighted,
    there no code is executed with elevated security.

  TODO:
  - Identify potential issues with installed applications and files for
    default ownership and permissions
  - For plugins in general (gnome-vfs, gstreamer, gnome-terminal, etc.)
    identify if a new plugin can be added via properties without the
    user realizing (by carefully crafted data, poor permissions, etc.)
  - More information about what security interfaces are used for each
    component and why was that technology selected.

+ a11y

  - Note: AT stands for "Accessible Technology", which in this context refers
    to any client program that uses the ATK interfaces.

  - The a11y daemon (at-spi-registryd) allows AT programs to listen to all
    activity in any GTK+ program, although password fields are not sent across.
    If ORBit were compromised, then this data could be sniffed.   See below
    for information about ORBit.

    For example, a malicious AT program (an AT program designed to use the
    a11y interface) could sniff all activity in all programs that support the
    ATK.  Much the same as running a trojan program that listens to the Xserver
    calls.

  - a11y requires that Xserver grabs and keyboard locks be relaxed somewhat
    so that programs like the xscreensaver can not grab the server.  This
    makes such programs less secure to trojan processes listening to X.

  - To support accessibility with Java, it is necessary to set up ORBit
    in Java-Interopability, single-machine mode.  Refer to ORBit section.

  - Some AT programs have a special LoginHelper property which will allow
    special privileges at times when the screen is locked, etc.  For example,
    the xserver lock may be released, keyboard might be unlocked to that client
    (only), specific windows might be raised above the login dialog.  The
    proposal includes a 'setSafe' API so that the services are asked to "go
    into safe mode" first, to mitigate any potential exploit of those AT's
    while the screen is locked.  SO provided the AT's are intelligently
    written, and they assert that they have indeed gone into a
    "security-conscious" mode with limited permissions, things remain pretty
    safe.

    TODO:
    Need to add information about how the LoginHelper property is set.
    Whether there are ways to identify such programs without the source,
    and whether it can be disabled.  Some examples of how it is expected
    to be used would also be useful.

+ bonobo

  - These programs use bonobo/ORBit for all inter-process communications and
    depend on it for security:
    * at-spi-registryd
    * bonobo-activation-server
    * evolution
    * gnome-panel/gnome-applets
    * gconfd
    * nautilus

  - Implementation the GNOME component layer, allowing inter-process
    communication.

  - bonobo-activation allows the activation of services on the desktop (such
    as the at-spi-registryd).  If ORBit were compromised, then it would be
    possible to get an IOR for anything that can be activated on the desktop
    and client calls could be made.

  - Bonobo components are, by default, identified by an OAFIID.  The components
    are specified by files with the .server extension and are contained by
    default in the lib/bonobo/servers directory.  These files contain the
    following line to map the OAFIID to an executable (typically stored in
    libexec).

    <oaf_server iid="OAFIID:Foo_Factory" type="exe"
        location="/libexec/foo">

    These server files are only writable by root to protect against a malicious
    user redefining the mappings.  The lib/bonobo/servers directory is writable
    only by root, so only root can register new OAFIIDs by install new
    components.

  - etc/bonobo-activation specifies a list of directories that
    can contain bonobo modules in addition to the lib/bonobo/servers default
    directory.  By default, this file contains no additional directories.

  - Note that bonobo components support extensions that can be defined by the
    program intending to use the component.  For example, gnome-applets
    are components that can only be launched by programs that support
    gnome-panel extensions, and nautilus components can only be launched by
    programs that support nautilus view container extensions.

+ esd

  - Default configuration is stored in etc/esd.conf, which is writable only by
    root.

+ evolution

   - Uses TLS/SSL for encrypting communication between mail program and server.

   - Build in PGP/GPG cryptographic verification.

   - Supports SASL (Simple Authentication and Security Layer).

   - Supports IMAP, POP3, SMTP and authenticated SMTP protocols.

   - Supports SMTP authentication with the following types: PLAIN, LOGIN,
     CRAM-MD5, and DIGEST-MD5.

  - md5 is used to get the thumbnail name for certain image files,
    following the TMS (Thumnail Managing Standard).

   - Uses libghttp.

+ evolution xchange

  - Microsoft Exchange 2000 and 2003 support.
  - WebDAV support.
  - Access, edit, and update email, address book, calenders, and task folders
    on the Exchange server from within Evolution.
  - Can control access to personal and public folders, calenders, and task
    lists.

+ gaim

  - Supports AIM (Oscar and TOC protocols), ICQ, IRC, Jabber, YIM (Yahoo
    Instant Messanger), MSN, Gadu-Gadu, Zephyr,  SILC, and Novell
    GroupWise protocols.   AIM TOC protocol is no longer actively supported.

  - Sending and receiving of files on AIM, IRC, Jabber, and Yahoo is
    supported.

  - Refer to GnuTLS, which gaim uses.

  - Security information detailed in the following documents in the source
    tree:
    - src/protocols/irc/PROTOCOL

  TODO:  Detail security information about how it deals with passwords and
         sensitive data.

+ gconf

  - gconf is used to store configuration data for most GNOME applictions.
    Configuration data is stored in a hierarchy of files in XML format.  Each
    directory in the hierarchy contains a file named %gconf.xml that contains
    configuration data in key/value format.

    Gconf data is referenced by a key.  This key specifies both the location
    in the directory hierarchy and the actual key used in %gconf.xml file in
    that directory.  For example, a gconf key named /dir1/dir2/foo would
    return a the value for the key foo found in the dir1/dir2/%gconf.xml file.

    Note that some low-level components that GNOME depends upon do not use gconf
    and use different mechansims for storing configuration data (such as ORIBit)

  - gconf configuration data can be stored in different directories.   This
    allows mandatory, user, and default settings to be specified in different
    locations.  If any of the gconf configuration files were compromised, then
    the appearance of GNOME programs and preference configuration could be
    modified without the user being aware.  File permissions are used to
    protect against such a compromise.

  - When the gconfd daemon receives a read request for a gconf key, it uses
    the /etc/gconf/2/path file to determine where to find the key's value.
    If a particular gconf key isn't found in the first directory searched, the
    directories are then searched in order until the key is found.  The path
    file contains a list of directories (specified as readonly or readwrite)
    and include statements.  The include statements allow additional path files
    to be included in the search order.  This is useful to allow local system
    and user defined path files to be included in the search.  By default,
    these directories are:

    xml:readonly:/etc/gconf/gconf.xml.mandatory
    include /etc/gconf/2/local-mandatory.path
    include "$(HOME)/.gconf.path"
    xml:readwrite:$(HOME)/.gconf
    include /etc/gconf/2/local-defaults.path
    xml:readonly:/etc/gconf/gconf.xml.defaults

    As can be seen, readonly mandatory settings are searched first, and these
    settings are located in etc/gconf/gconf.xml.mandatory by default.  The
    search continues to any directories specified in the
    etc/gconf/2/local-mandatory.path file.  Next, the user-writable settings
    located in $HOME/.gconf are searched.  If the gconf key is still not found,
    default values are checked.  First, any directories defined in
    /etc/gconf/2/local-defaults.path and then in the
    /etc/gconf/gconf.xml.defaults directory.

    By default, the /etc/gconf/2/local-mandatory.path and
    /etc/gconf/2/local-defaults.path are not installed on the system.  They
    must be created by the system administrator if desired.

    For example, the search order for key dir1/dir2/foo would be as follows
    (assuming that the /etc/gconf2/local-mandatory.path and
    /etc/gconf/2/local-defaults.path do not exist):

      /etc/gconf/gconf.xml.mandatory/dir1/dir2/%gconf.xml
      $HOME/.gconf/dir1/dir2/%gconf.xml
      /etc/gconf/gconf.xml.defaults/dir1/dir2/%gconf.xml

  - All of the directories and files in /etc/gconf are writable only by root
    and the $HOME/.gconf directory is read/write only by user to protect user
    settings from being visible to other users and to prevent any tampering.

+ gdm

  - GUI runs as user gdm and communicates with a separate process running
    as root which handles all interactions that require root authority
    such as authentication, changing device permissions, etc.  This
    provides similar protection to Solaris RBAC (Role Based Access
    Control), which is not currently used in gdm2.

  - Supports xauth cookies of type MIT-MAGIC-COOKIE that are of length 16.
    It uses the MD5 message-digest algorithm by Ron Rivest and Colin Plumb.
    This logic works as follows:

    To compute the message digest of a chunk of bytes, declare an
    GdmMD5Context structure, pass it to gdm_md5_init, call
    gdm_md5_update as needed on buffers full of bytes, and then call
    gdm_md5_final, which will fill a supplied 16-byte array with the
    digest.

    To create keys that are as random as possible, especially for platforms
    that do not support /dev/random and /dev/urandom, gdm_md5_update is
    called with the output from many different files.  The following
    structure defines the path, length of data read, and seek value
    for all reads passed into gdm_md5_update.  Note that MAXBUFFERSIZE
    is defined to be 1024.  Also note that #ifdef's are used to support
    different files for different platforms.

    { "/dev/random",              16,    0 },
    #ifdef __OpenBSD__
    { "/dev/srandom",             16,    0 },
    #endif
    { "/dev/urandom",            128,    0 },
    { "/proc/stat",    MAXBUFFERSIZE,    0 },
    { "/proc/interrupts", MAXBUFFERSIZE, 0 },
    { "/proc/loadavg", MAXBUFFERSIZE,    0 },
    { "/proc/meminfo", MAXBUFFERSIZE,    0 },
    #if defined(__i386__) || defined(__386__) || defined(_M_IX86)
    /* On i386, we should not read the first 16megs */
    { "/dev/mem",      MAXBUFFERSIZE,    0x100000 },
    #else
    { "/dev/mem",      MAXBUFFERSIZE,    0 },
    #endif
    /* this will load the old authfile for the display */
    { NULL /* null means the authfile */, MAXBUFFERSIZE, 0 },
    { "/proc/net/dev", MAXBUFFERSIZE,    0 },
    { "/dev/audio",    MAXBUFFERSIZE,    0 },
    { "/etc/shadow",   MAXBUFFERSIZE,    0 },
    { "/var/log/messages",   MAXBUFFERSIZE,      0 },

  - Supports XDMCP, though this is turned off by default (at Gary Winiger's
    recommendation).  gdm2 uses the standard port 177 as the XDMCP default.

  - Uses PAM for authentication.  All PAM code has been reviewed by Gary
    Winiger, Sun's PAM expert.  All significant code change recommendations
    that Gary made were implemented by George Lebl, the gdm2 maintainer.

  - Plan to support Solaris auditing API

  - Plan to support logindevperm for changing device permissions for user
    on login.

  - The gdm.conf file is used for configuring the behavior of gdm.  It
    requires root authority to modify.  Several gdm configuration parameters
    have security implications:

    * The Group and User gdm.conf option specifies the userid and
      group that is used to run the gdmchooser/gdmlogin GUI programs.

    * The TimedLoginEnable gdm.conf option (set to false by default)
      causes a specified user to be automatically logged in after a
      certain time.  The TimedLogin, and TimedLoginDelay gdm.conf
      options affect how this feature works.

    * The AutomaticLoginEnable gdm.conf option (set to false by
      default) causes a specified user to be automatically logged
      in upon first bootup.  The AutomaticLogin gdm.conf option
      affects how this feature works.

    * SystemMenu gdm.conf option (set to false by default) turns
      on a menu which allows the user to Halt, Reboot, or Suspend
      the system.  The HaltCommand, RebootCommand, SuspendCommand
      gdm.conf options specify the commands to run if this menu
      is made active.

    * AddGtkModules gdm.conf (set to false by default) option
      specifies that GDM_MODULES will be loaded with gdmlogin and
      gdmgreeter.  The GtkModulesList gdm.conf option specifies
      the modules to load.  These are needed for accessibility
      gesture listener support.

    * GtkModulesList option specifies the GTK modules that will be
      loaded when any gdm GUI program is launched.  These programs
      are run as the user gdm.  By default the modules include:

        gail
        atk-bridge
        lib/gtk-2.0/modules/libdwellmouselistener
        lib/gtk-2.0/modules/libkeymouselistener

      The gail and atk-bridge modules make up the a11y infrastructure
      and are required for general a11y support.  The gail module
      implements the ATK interface for GTK-based widgets and the
      atk-bridge communicates ATK events to AT programs such as GOK
      and gnopernicus.

      The libkeymouselistener supports key and mouse button gestures that
      are defined in the etc/X11/gdm/modules/AccessKeyMouseEvents file.
      The libdwellmouselistener supports mouse motion gestures that are
      defined in the etc/X11/gdm/modules/AccessDwellMouseEvents file.

      Both the AccessKeyMouseEvents and AccessDwellMouseEvents file
      specifies a list of gestures and commands.  If the gesture
      listener module is included in the GtkModulesList option and the
      AddGtkModules argument is set to true, then the specified
      command is launched when the gesture is received.

      Currently the AccesskeyMouseEvents and AccessDwellMouseEvents
      file are used to launch gnopernicus (srcore) and GOK as
      follows.

      AccessDwellMouseEvents:

         TBLR I 10000    gok --login --access-method=dwellselection

      AccessKeyMouseEvents:

         # hold right or left mouse button 3 times for 3 seconds each time
         <Mouse1> 3 3000 10000 gok --login --access-method=directselection
         <Mouse3> 3 3000 10000 gok --login --access-method=directselection
         <Mouse3> 3 3000 10000 gok --login --access-method=directselection

         # same as above for XInput devices
         <Switch1> 1 5000 0 gok --login --access-method=automaticscanning
                                --scan-action=switch1 --select-action=switch1
         <Switch2> 3 50 3000 gok --login --access-method=inversescanning
                                --scan-action=switch1 --select-action=switch2
         <Switch3> 3 1000 10000 gok --login  --access-method=automaticscanning
                                --scan-action=switch3 --select-action=switch3

         <Control>s  1 1000 10000  srcore --login --enable-speech
         <Control>m  1 1000 10000  srcore --login --enable-magnifier
         <Control>g  1 1000 10000  srcore --login

    * The AllowRoot and AllowRemoteRoot gdm.conf options (set to
      false by default) allow root to login on the console.

    * The AllowRemoteAutoLogin gdm.conf option allows remote login.

    * The Browser gdm.conf option (set to false by default) turns
      on the face browser.

    * The ServAuthDir, UserAuthDir, UserAuthFBDir, and UserAuthFile
      gdm.conf options specify the location of Xauth files.

    * The Enable gdm.conf option turns on XDMCP.  The Port gdm.conf
      option specifies the port used.

  - For a11y support, GTK modules are used.  These modules are loaded
    at runtime when gdm GUI programs are started when the AddGtkModules
    gdm.conf configuration argument is set to tru.  The specific modules
    loaded are defined with the AddGtkModules gdm.conf configuration
    argument specified above.

+ gedit

  - Supports a plugin mechanism that can display information or perform
    transformation on the loaded document.  The following plugins are
    loaded by default:

    + Document Statistics
    + Indent lines
    + User name
    + Shell command
    + Sort
    + Tag list
    + Insert Date/Time

    Default plugins are specified by the /apps/gedit-2/plugins gconf key.
    Additional plugins will be loaded if they are in the
    $HOME/.gedit-2/plugins directory.   Refer to the gconf section for
    gconf security.  The .gedit-2 directory must be created by the user
    and should obviously be created with user-write only permission to be
    secure.

+ gimp

  - Default configuration is stored in /etc/gimp.  The directory and the
    files contained are writable only by root.

  - md5 is used to get the thumbnail name for certaim image files,
    following the TMS (Thumnail Managing Standard).

+ glib/GTK+

  - Glib's spawn functions are used for spawning synchronous and/or
    asynchronous processes (g_spawn_sync and g_spawn_async).  A flag,
    G_SPAWN_SEARCH_PATH, can be passed in to allow searching of PATH
    for the program.  If the flag is unset, the full pathname of the
    executable must be used.  The convenience functions
    g_spawn_command_line_sync, g_spawn_command_line_async always set
    this flag.

  - If the PATH environment variable is unset, glib uses the following
    string instead:

        "/bin:/usr/bin:."

  - The GTK+ library are not guaranteed to be secure, so programs
    written using GTK+ will not run with set uid or gid permissions.

    Typically when GTK+ programs require set uid, a separate process with
    no GUI is used to handle permissions which interacts with a separate
    GUI process that has no additional permissions.

    GTK+ uses getresuid()/getresgid() to determine that uid == euid
    and gid == egid.   Since these functions are not present on Solaris,
    getuid()/getgid() are used to get uid/gid and geteuid()/getegid()
    are used to get euid/egid.  In uid != euid or gid != egid, the
    execution of the program is stopped.

    Note that GTK programs can be written to have setuid/setgid permissions
    as long as the setuid/setgid privileges are dropped before GTK+ is
    initializes (this is how gnome-games works).

    TODO:  Any reason why issetugid() is not used?

  - It is possible to run code in-process via dlopen when running GTK+
    based applications.  This can be done by setting the name of the
    module to load via the GTK_MODULES environment variable or via the
    "--gtk-module=foo" command-line argument.  dlopen is used to open
    the module, so the only way to limit what modules can be loaded
    is by controlling dlopen.

    An example of where modules are used in GNOME would include a11y
    gesture listeners, which are used to recognize when a person with
    a disability is making a gesture intended to launch an application
    needed to access a running program.

  - Input method shared objects are plug-ins that are loaded with all
    GTK+ applications.  They are specified in the /etc/gtk-2.0/gtk.immodules
    file, which is writable only by root.

  - GTK stores its default pixbuf loaders and input method modules in the
    /etc/gtk-2.0/gtk-pixbuf.loaders file, which is writable only by root.

+ gnome-applets

  - gtik (stock-ticker)
    * uses gnome_vfs to access
      http://finance.yahoo.com/d/quotes.csv?s=

  - gweather
    * uses gnome_vfs to access
      http://weather.noaa.gov/cgi-bin/mgetmetar.pl?cccc=%s

+ gnome-games

  - The games are given special gid privileges so that the high score files
    can not be written to directly by the user.  This can be disabled by
    the --disable-setgid configuration option, though this causes the high
    score files to be disabled.  On Solaris we package gnome-games without
    setgid privileges in the package maps rather than using the
    --disable-setgid configure option.

  - Note that GTK+ does a check when it is initialized to verify that the
    program is not running with elevated permissions.  All setgid gnome-games
    drop setgid permissions after opening the high score file for writing
    and before initializing GTK.

+ gnome-keyring

  - Keeps a keyring of the user's passwords on the filesystem.  Uses AES to
    protect passwords.

  - Following overview written by Alexander Larsson, refer to:
    http://mail.gnome.org/archives/desktop-devel-list/2003-November/msg00555.html

    Conceptually, the keyring manager manages a set of keyrings. Each
    keyring contains a set of keyring items, where each item stores a
    secret, typically a password.  To identify the items, it has a
    set of named attributes, with values that are utf8 strings or
    integers. Each item also has additional data such as: mtime, ctime,
    display name and item type. Keyrings are normally locked, meaning that
    their content is encrypted, and not available for apps to use without
    the keyring password.

    Apps would use this by issuing a search for a password with the known
    information. Say you want to log in to "smb://someserver/someshare",
    you'd then query for an item of type network password with attribute
    server="someserver", path="someshare", protocol="smb" and you'd get
    back a list of items that matches this, where you can read the secret,
    and also the full attribute list containing username, nt domain etc.

    If a search or any other operation needs access to an item on a
    locked keyring then the user will get a dialog asking for the master
    password of the keyring to unlock it. Each item also has an access
    control list, which controls what apps are allowed access to the
    item, so that when an app tries to access an item it isn't allowed to
    access the user will get a dialog where he can allow or deny the
    access.

    There is also a keyring named "session", which isn't backed by a
    file. This can be used to store passwords for the current session
    only.

    Implementation-wise gnome-keyring is very similar to ssh-agent. You're
    supposed to launch the daemon early in your session and it'll output an
    variable that you set in your environment. This will let applications
    find the unix domain socket to communicate with the daemon, and will
    make the daemon connect to the right session and the right X display.

    The daemon itself is a very small, glib-only application that uses a
    custom protocol over unix sockets (can't use CORBA because we need
    some special features like SO_PEERCRED, and I want the daemon to be
    minimal for security reasons). All user interaction is done by a
    separate program (gnome-keyring-ask) that the daemon spawns when
    needed (if it notices that DISPLAY is set).

    The keyring files are stored in ~/.gnome2/keyrings, and are encrypted
    with the AES block cipher and SHA1 is used for hashes. All data about
    the items is encrypted, except item type and a hashed version of the
    attributes. The hashed attributes allows us to match on items even
    when the keyring is locked, so that you'll only be prompted for the
    keyring password if a search really matches an item in a locked keyring.

    There are certain security aspects in the storage of passwords like
    this. If the user choses a good password, the passwords are safely
    stored in encrypted files when the user is not logged in, but when the
    user is logged in and a keyring is unlocked, both the keyring
    password and all the secrets stored in the keyring are stored in the
    memory of the keyring daemon. So, if someone has root on the machine,
    he'll be able to read the memory of the daemon and steal your
    passwords (i.e. only use this on machines you trust). Other users on the
    machine will not be able to do this, because only processes with the uid
    of the daemon will be allowed access.

    There is even some protection against user of your own uid,
    ptrace and process memory access can be disabled by making the binary
    chmod u-r (on Linux), and the ACLs allow some form of protection
    against buggy applications, but not perfect protection against malicious
    code. To get the ACLs safe against malicious code (viruses, trojans,
    etc) we would need to extend gnome-keyring with some selinux features.
    This could be done in the future without changing the APIs.

+ gnome-netstatus

  On Linux, we ship ifrestart as a part of gnome-netstatus.  ifrestart is used
  to restart the network interfaces.  This is necessary when you get a new IP
  address, such as when you get a new lease on a wireless network or when a
  cable comes unplugged.  To do this, elevated security is provided by
  consolehelper.  Details follow:

  1. What is ifrestart

  ifrestart is a script which permits, after one time set up, a console
  user to restart network interface without knowledge of root password.

  2. When ifrestart should be used

  The script might be utilized to reestablish network connection on a
  mobile system when the system moved between networks without reboot.

  3. What ifrestart uses

  A user can execute ifrestart by invoking a symbolic link /usr/bin/ifrestart.
  This link points to consolehelper application and is part of consolehelper
  framework agreement.  In its turn, consolehelper uses PAM in order to obtain
  root user privileges.  Unless PAM configuration file exists for ifrestart,
  consolehelper asks a user for root password.  Otherwise, PAM configuration
  file is used to verify rights of the user to execute ifrestart script.

+ gnome-session

  - The session manager uses the standard X ICElib to manage connections

  - gnome-session supports the following gconf boolean setting:

    apps/gnome-session/options/allow_tcp_connections

    For security reasons,  on platforms which have _IceTcpTransNoListen()
    (XFree86 systems), gnome-session does not listen for connections on
    TCP ports.  This option will allow connections from (authorized)
    remote hosts.  gnome-session must be restarted for this to take effect.

+ gnome-terminal

  - Supports utmp/wtmp

  - Supports s/key highlighting.  When you run
    "ssh user secure host com" in gnome-terminal, and secure.host.com
    has one-time password set up, then you get a different response
    from normal.

    You don't get "user secure host com's password:"

    You get:

      S/key one time passwords are in effect.
      Challenge: s/key 1234 sec98765
      Please enter s/key response:

    If you are reading this in a text-mailer in gnome-terminal,
    mouse over that middle line, and it will be highlighted
    and you can click on it.

    Now then, _normally_ you would take that middle line about
    s/key 9876 sec12345 (or whatever: it changes with every
    login attempt), feed it into a magic program for figuring
    out what your password is today, which will be valid for
    this one login only, and then type that one-time-password
    in at the prompt in the final line.

    Instead of feeding that middle line to another machine
    or program to get your magic phrase-of-the-day, if you click
    on the highlighted underlined text, you get a dialogue box
    which is an interface to a program which will do it for you.

    So you type in your _normal password_ to that dialogue box.
    The program behind it can see the s/key challenge and the
    numbers it has produced this time. And that program figures
    out your one-time password or phrase for the day and
    feeds it to the machine waiting for it. And you can log in.
    The dialogue box goes away and you can go back to your
    gnome-terminal having had the login happen automatically.

    s/key uses MD5 for encryption.

+ gnome-utils

  - dictionary (application and applet)
    * Uses a socket connection over IPv4 or IPv6 if enabled.  The
        default server is dict.org.

+ gnome-vfs and gnome-vfs-extras

  - These programs make use of gnome-vfs:
    * evolution and eel
    * gal
    * gpdf
    * gthumb
    * gtik (stock-ticker) applet
    * gtksourceview
    * gweather applet
    * libgnome
    * libgsf
    * nautilus and nautilus-cd-burner
    * planner
    * quick-lounge-applet
    * yelp

  - gnome-vfs stands for GNOME Virtual File System.  It provides an abstraction
    layer for reading, writing, and execution of files over various protocols.
    Different types of data can be accessed via a unique URI (Universal Resource
    Identifier) which works similarly to URL's in web browsers.

    How each URI is handled is defined by files with the conf extension in the
    /etc/gnome-vfs-2.0/modules directory.   For each unique URI the conf
    file specifies a shared object that is used for processing the data
    except for when the data type is a vfolder.  Vfolders correspond to
    specific virtual hierarchies that are specified by XML files with the
    vfolder-info extension in the /etc/gnome-vfs-2.0/vfolders directory.

    The /etc/gnome-vfs-2.0 directory and the files contained are writable only
    by root so that only root can add new modules or modify these files.

  - The following lists all .conf files that are installed by default and what
    URI's are supported for each module:

    Note that some protocols supported are not secure protocols.

    cdemenu-module.conf
       cdemenu         (access to CDE menu files)

    default-modules.conf
       bzip2                     (file compression format)
       cdda                      (CD Direct Digital Audio protocol)
       computer                  (hardcoded vfolder)
       file                      (file system0
       test
       ftp                       (File Transfer Protcol)
       nntp                      (Network News Transport Protocol)
       gzip                      (file compression format)
       http                      (HyperText Transfer Protocol)
       dava                      (Distributed Authoring and Versioning)
       pipe
       nfs                       (Network File System - uses the kernel's
                                  NFS implementation))
       sftp                      (SSH File Transfer Protocol)
       ssh                       (Secure Shell)
       tar                       (archive format)
       a ar arj                  (archive formats)
       cpio                      (archive format)
       deb                       (Debian binary package file format)
       hp48                      (HP48 external filesystem)
       lha                       (file compression)
       mailfs                    (Berkely style mailbox files)
       patchfs
       rar                       (file archive/compression format)
       rpm rpms trpm             (Red Hat Package file formats)
       zip                       (file archive/compression format)
       zoo                       (file archive/compression format)

       The following vfolder URI's are also supported:
         all-applications
         all-preferences
         applications
         applications-all-users
         favorites
         network
         network-all-users
         preferences
         preferences-all-users
         quick-start
         start-here
         system-settings
         server-settings

    extra-modules.conf   (modules provided by gnome-vfs-extras)
       smb                       (Samba)
       rio500                    (RIO500 USB)

    font-method.conf     (provided by control-center)
       fonts                     (interface for fontilus)

    mapping-modules.conf (provided by nautilus-cd-burner)
       burn                      (interface for cd burners)

    theme-method.conf    (provided by control-center)
       themes                    (interface for themus)

  - gnome-vfs supports mime-type sniffing and algorithmic detection.  This is
    used to identify the mime type of a file by parsing the content of the
    file to determine content.  Patters to support sniffing are stored in
    etc/gnome-vfs-mime-magic, which is writable only by root.

+ GOK (GNOME Onscreen Keyboard)

  - Can be executed as user gdm when launched from the login screen.   Refer
    to gdm section for details

  - Supports the --login command line argument so that GOK works properly
    with the limitations imposed by running as user gdm (e.g. no $HOME
    directory for saving gconf settings).

+ gnopernicus

  - Can be executed as user gdm when launched from the login screen.   Refer
    to gdm section for details

  - Supports the --login command line argument so that gnopernicus works
    properly with the limitations imposed by running as user gdm (e.g. no
    $HOME directory for saving gconf settings).

  - Default translation tables are stored in etc/gnopernicus-1.0.  This
    directory and its contents are writable only by root.

+ GnuTLS (GNU Transport Layer Security Library)

  Websites:
    http://www.gnu.org/software/gnutls/

  - Used by gaim, libsoup, and vino.  libsoup is used by gtkhtml, hydrogen,
    and oxygen.

  - Provides a secure layer, over a reliable transport layer.  Currently
    the GnuTLS library implements the proposed standards by the IETF's
    TLS working group.

    Quoting from RFC2246 - the TLS 1.0 protocol specification:

    "The TLS protocol provides communications privacy over the Internet.
    The protocol allows client/server applications to communicate in a way that
    is designed to prevent eavesdropping, tampering, or message forgery."

    Features

    * Support for TLS 1.0 and SSL 3.0 protocols
    * Support for TLS extensions
    * Support for authentication using the SRP protocol
    * Support for authentication using both X.509 certificates
    * and OpenPGP keys Support for X.509 and OpenPGP certificate handling.
    * Supports all the strong encryption algorithms
    * Supports compression
    * Runs on most Unix platforms

+ gstreamer

  - Plugins are identified as being available via the Gstreamer registry file
    which is in XML format.  If the user registry exists, it overrides the
    Global registry.  File permissions prevent writing to the Global file if
    not the root user, and prevent writing to the user file if not the user.
    * Global - /var/cache/gstreamer-0.8/registry.xml
    * User   - $HOME/.gstreamer/registry.xml

  - No real risk aside from buffer overflows and access to possibly insecure
    protocols.  Though sending sensitive audio/video information over
    insecure protocols might need to be highlighted to the user.  Again, the
    system could be set up to run TCP/UDP over SSH or SSL, though this is not
    how things run by default.  The following protocols are supported:
    - Has tcp and udp plugins (tcpserversink, tcpserversrc, tcpclientsrc,
      tcpclientsink, udpsrc and udpsink).
    - Has a gnome-vfs plugin allowing access to gnome-vfs modules.  See
      below for more information about gnome-vfs.

  - Most bitstream formats (such as ogg/vorbis) do not support encryption
    or certification mechanisms.  If such are desired, external security
    mechanisms must be added if content confidentiality and authenticity
    is to be achieved.

+ libghttp and libghttp-evolution (similar libraries)

  - Both libraries simply manage HTTP connections using sockets.

+ libgnome

  - User configuration that have security or privacy implications are
    stored in the $HOME/.gnome2_private directory, which has read
    permission only for the user.  Other configuration is stored in
    the $HOME/.gnome2 directory.  The .gnome2_private directory is
    given 700 permissions when created.  It is not subsequently
    checked to verify that the permissions are always 700.

+ NOW

  - Uses WCAP protocol to interact with iCalendar server.  NOW uses
    libghttp to manage a HTTP connection to the iCalender

+ ORBit

  Websites:
    http://orbit-resource.sourceforge.net
    http://orbit-resource.sourceforge.net/faq.html
    http://www.gnome.org/projects/ORBit2/
    http://www.gnome.org/projects/ORBit2/orbit-faq/faq/faq.html

  - ORBit uses a function named ORBit_genuid_init to generate the magic
    cookie.  This generates a 128bit random number via /dev/urandom.
    If /dev/urandom does not exist on the system, then /dev/random is
    used.

  - ORBit can be run in three modes.  These are:
    - Lock-Down Single User Mode (normal default).  This is specified with
      the ORBit ORBIIOPUSock or ORBIIOPUNIX option (they are synonymous).
      Sockets are used for all CORBA transactions.  The sockets are placed in
      a user-owned directory named /tmp/orbit-$USER with read/write/execute
      permissions only for the user.  In other words, this case boils down to
      "if you can become the user, then you can do anything as that user".
    - Java-Interopability, single-machine mode (default for Solaris to
      support a11y with Java applications).  This is specified by using the
      ORBit ORBIIOPIPv4 or ORBIIOPIPv6 option with the ORBLocalOnly option.
      Transactions are handled over TCP/IP but connections are only allowed
      from the local machine.
    - Wide-Open.  This is specified by using the ORBit ORBIIOPIPv4 or
      ORBIIOPIPv6 option without the ORBLocalOnly option.  Transactions are
      handled over TCP/IP and connections are allowed from anywhere.

  - When TCP/IP is used without the ORBLocalOnly option, ORBit obviously
    becomes vulnerable to typical TCP/IP attacks including Denial-Of-Service
    attacks.  It is also vulnerable to malign use if the magic cookie used to
    protect ORBit connections were known.  Example of misuse would be spoofed
    client requests or buffer-overflow attacks.

    A case where ORBit would need to be run over TCP/IP would be if
    the user wants better session support across multiple sessions.
    Running ORBit over TCP/IP allows various GNOME daemons to be shared
    across a network.  The system could be set up to run TCP/IP over SSH
    or SSL, though this is not how things run by default.

    It is recommended to enhance the Java ORB to work directly with ORBit
    sockets, so Java a11y could be supported without needing to make ORBit run
    over TCP/IP.

  - ORBit supports the following options that have security implications:
    - ORBIIOPSSL    - Uses OpenSSL.  ORBit is set up to never compile the code
                      to support OpenSSL due to licensing issues.
    - ORBHTTPIORs   - Can only be used if ORBit is configured with --enable-http
                      which is non-default.  Allows HTTP connections to ORBit.
    - ORBSimpleUIDs - This turns on simple cookie generation, which builds
                      a fairly insecure magic cookie via the following logic
                      (formatting slightly modified for readability):

                      genuid_simple (guchar *buffer, int length)
                      {
                        static guint32 inc = 0;
                        g_assert (length >= 4);
                        p_memzero (buffer, length);

                        if (length > 4)
                                memcpy (buffer + 4, &genuid_pid, 4);
                        if (length > 8)
                                memcpy (buffer + 8, &genuid_uid, 4);

                        INC_LOCK ();
                        inc++;
                        memcpy (buffer, &inc, 4);
                        xor_buffer (buffer, length);
                        INC_UNLOCK ();
                      }

  - ORBit supports a function called ORBit_small_load_typelib, which loads
    type libraries.  If an absolute pathname is not passed in, the
    ORBIT_TYPELIB_PATH and GNOME2_PATH environment variables are used to
    scan for type libraries.

+ nautilus

  - Nautilus will not launch files if the sniffed mime-type (using gnome-vfs
    sniffing, refer to gnome-vfs) does not match the mime-type associated
    with the file's extension.  The "Open With" menu option must be used to
    open such files.

  - Nautilus will not launch executable files from remote locations where the
    uri scheme isn't "file://".  The "file://" exception is because files on,
    for example, nfs are treated as remote.

+ openh323/pwlib (used by gnome-meeting)

  - Implementation of the ITU H.323 teleconferencing protocol.  The following
    protocols apply to H.323 which have security implications:

    + H.235 - Security and encryption for H-series (H.323 and other H.245-based)
              multimedia terminals

    Refer here:

    http://www.itu.int/rec/recommendation.asp?type=products&parent=T-REC-h

+ pango

  - pango modules are shared objects that are loaded when needed.  The mapping
    of shared objects to languages is stored in etc/pango/pango.modules, a file
    that is only writable by root.

  - The etc/pango/pangox.aliases is a file that contains font mappings.  This
    file is only writable by root.

+ scrollkeeper

  - scrollkeeper-get-cl program creates temporary files named
    /tmp/scrollkeeper-$USER/scrollkeeper-tempfile.x (where x is a number
    from 0 to 4).  This temp file is used to store the merged XML content
    index.  These files are stored in a user-owned directory with only
    user write permissions.

  - Default scrollkeeper configuration is stored in the etc/scrollkeeper.conf
    file, a file that is only writably by root.

+ sound

  - Default system sounds are defined by files with the soundlist extension in
    the etc/sound/events/ directory.  This directory and its contents are
    writable only by root.

+ totem

  - Totem has its own IPC system that is used to send messages from
    the client to the server.  It uses a user writable socket in /tmp.
    This does make the socket vulnerable on systems that do not honor
    file permissions for sockets.  It unfortunately uses a predictable
    file name and does not use a subdirectory of /tmp.  No protection
    against someone else creating a socket with the right name in /tmp
    before it gets set up.  Fortunately this is socket is only used
    for message parsing that does not cause code to get executed.
    However this could be vulnerable to Denial-Of-Service attacks or
    buffer overflow.

+ xslt

  - Supports a security framework.  These include  APIs to be able to define
    security preferences dynamically (either global or per transformation):
    The xsltproc command supports the following arguments:
        --nowrite           - refuse to write to any file or resource
        --nomkdir           - refuse to create directories
        --writesubtree path - allow file write only within path subtree.
        --nonet             - do not use the internet to fetch DTD's or entities

    Basically --nowrite will block exslt:document on-the fly document
    creation, while --nomkdir will limit itself to block directory creation.

    The current set of options where the policy can be defined are exported
    from <libxslt/security.h> :
        XSLT_SECPREF_READ_FILE
        XSLT_SECPREF_WRITE_FILE
        XSLT_SECPREF_CREATE_DIRECTORY
        XSLT_SECPREF_READ_NETWORK
        XSLT_SECPREF_WRITE_NETWORK

+ vino

  - Security information detailed in the remote-desktop.txt file in the docs
    subdirectory of the module.  Some relevant details from this document below:

  - VNC uses a simple DES based challenge-response authentication mechanism.
    In order to authenticate the client, the server sends a random
    16 byte challenge and the client then encrypts the challenge with DES
    using the user supplied password as a key. If the response matches the
    expected result, the client is authenticated. Otherwise, the server
    closes the connection. There are a number of possible vulnerabilities
    with this mechanism.

  - Supports version 3.7 of the RFB protocol to add security negotiation.
    In order to protect the VNC session from such attacks, the protocol should
    be extended to allow the stream to be encrypted. Luckily, the RFB protocol
    was designed to allow such extensions while maintaining compatibility.

    The encryption of the RFB stream will be implemented with TLS/SSL[26] using
    the gnutls[27] library and, for the Java client, the Java Secure Socket
    Extension (JSSE)[28].

  - Refer to GnuTLS, which vino uses.

--

Brian




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]