GNOME security
- From: Brian Cameron <Brian Cameron Sun COM>
- To: desktop-devel-list gnome org
- Subject: GNOME security
- Date: Wed, 21 Jul 2004 15:56:42 -0500
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]
