issue on Yum & Xattr
by Park Lee
Hi,
I have several questions there:
When we use the command 'yum', must we keep on line? Can I use it on my local machine?
Where is the extended attributes stored? in the inode?
Is there any text-based web browser that can be used in SELinux?
I greatly appreciate your answer.
Yours,
Park Lee
2004-06-05
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger
19 years, 10 months
Summary of Informal SELinux Meeting on May 6, 2004
by Karl MacMillan
An informal meeting of SELinux developers was held on May 6, 2004 at Tresys
Technology in Columbia, Maryland. Below are some notes from that meeting.
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134
Summary of Informal SELinux Meeting
Columbia, Maryland, USA, 6 May, 2004
An informal meeting involving a group of some of the key contributors to the
development of SELinux was held on May 6, 2004, at Tresys Technology, in
Columbia, Maryland, USA. A small gathering was initially prompted by Russell
Coker's visit to the Washington, D.C. area, but evolved into a larger
informal meeting. The purpose of the meeting was to have informal, real-time
discussions about the current status, challenges, and future of SELinux.
ATTENDANCE
Joshua Brindle Hardened Gentoo
David Caplan Tresys Technology
Jim Carter National Security Agency
Russell Coker Red Hat
James Griffin
Howard Holm National Security Agency
Jeff Johnson Red Hat
Peter Loscocco National Security Agency
Karl MacMillan Tresys Technology
Frank Mayer Tresys Technology
Stephen Smalley National Security Agency
Eamon Walsh National Security Agency
Via conference call:
James Morris Red Hat
Dan Walsh Red Hat
WORKSHOP
There was discussion of whether there was a need for establishing a regular
forum, similar in nature to this meeting, aimed at examining the state of
SELinux development. Specific issues discussed included the target audience,
duration, scheduling, and potential sponsorship of the meetings. Tresys
volunteered to organize an initial meeting in the Baltimore/Washington area
some time in the fall. It was assumed that this area would accommodate the
largest likely user participation. Additionally, there was some discussion
as to whether the audience should be limited to core developers or extend to
a more general population. The consensus was to model it after the Ottawa
Linux kernel conference, which involves an initial meeting of core
contributors followed by a more general symposium. The possibility of adding
tutorials to this structure was also discussed. Finally, corporate
sponsorship and government participation will be investigated.
FEDORA CORE
A brief update on the status of SELinux and Fedora Core 2 was given. The
need for transparency and limited user interaction with SELinux was
mentioned as a motivating requirement for much of the work that Red Hat has
done. The discussion quickly branched off into details about the policy and
policy management as Russell mentioned specific challenges Red Hat had
encountered with their integration of SELinux.
POLICY
The current state of the public "default" policies was discussed. The set of
default policies includes the original example base policy distributed by
the NSA, the Fedora core policy, and the recently released targeted (or
relaxed) policy. The new targeted policy was written with the aim of
isolating a limited set of services or daemons and allowing the rest of the
system to be relatively unaffected by the SELinux policy. The purpose of
this is to provide an example policy that the general Linux population will
be comfortable with (i.e., one that will minimally interfere with their
accustomed operations) yet would show how SELinux can provide a level of
protection from a service that at some time may be compromised. It makes the
initial policy easier to analyze and provides groundwork for slowly
introducing increased protection from the policy.
Providing the targeted policy as the default might help SELinux gain
acceptance, but it is not without potential drawbacks. A possible con to
this strategy is that it may make application developers less likely to
alter their software to work with SELinux or, where appropriate, be aware of
SELinux. This goes against the strong objective to have application
developers accept and integrate SELinux controls. Additionally, the targeted
policy makes only limited use of the user and role features of SELinux
because all users are placed in the same context. It is not clear whether
this exposes an area of the policy language that needs additional thought.
The desirability of modifying applications to be SELinux aware was
discussed. A goal of SELinux is to allow the use of unmodified applications.
Certain core system utilities need to be modified to be aware of SELinux
(init for example), but in general it is possible to create policies that
work with unmodified applications. There was a general consensus that the
requirement to modify applications has been a limiting factor to the
acceptance of other operating systems with mandatory access controls. This
does not mean, however, that it is not desirable to make SELinux specific
modifications to certain trusted system services.
One example that was mentioned is that it is difficult to create optimal
policies for certain types of applications. In particular, the Samba daemon
needs the ability to access files with a wide variety of labels in order to
service the requests of different users. It is desirable, however, to have
SELinux limit the types of files that Samba will access on behalf of a
specific user. The standard practices for handling this situation, like
executing a separate Samba daemon for each user, will not work in this
circumstance because of some details of the SMB/CIFS protocol. It was argued
that Samba is a trusted application and it would be appropriate, therefore,
to allow it to enforce SELinux access decisions by becoming a user-space
object manager. See the "Policy Management" and "Security Enhanced X Status"
sections for more details about user-space object managers. The conditional
policy features were briefly discussed. It was suggested the conditional
policy features could be used to grant privileges to daemons only on
startup, similar to a setuid application dropping capabilities. Using the
fine-grained labeling of the boolean files in the selinuxfs it is possible
for an application to remove access privileges (through setting a boolean)
and not have sufficient access privileges to turn them on again. The policy
discussion ended with a consensus that it is a mistake to try to overreach
on our goals (and likely come up short) on the initial versions of SELinux
policies for mainstream users; instead, the initial goal should be to manage
expectations of the general community to gain acceptance of type enforcement
a little bit at a time.
POLICY MANAGEMENT
There was a lengthy discussion on how best to manage policy and the
associated file context information. It was clear from the discussion that
this is an area that has many unsolved challenges. Though no definitive
solutions were determined, several motivating requirements emerged from the
discussion and are detailed below.
Local customizations
One of the issues that has arisen as part of the Fedora Core 2 development
process is how to handle local customizations to the policy on upgrade.
Currently, user modified changes are overwritten by RPM on upgrade of the
policy unless they are marked noreplace in the rpm spec file (tunables.te
for example). Users must manually merge the changes from the update for
files marked noreplace that had local customizations. All of the other
customizations to the policy are lost on update. Gentoo handles this problem
by presenting the user with diffs for all changes to files in /etc. The
general consensus was that this is not an appropriate solution for the
target audience of Fedora Core, but no other solution emerged.
RPM Integration
There was a lengthy discussion of integration with RPM. RPM is seen as a
primary delivery mechanism for policy and file labels. Currently, RPM can
record a single label for each file in the package and sets that label at
installation time. The policy for each application is not contained with the
package that provides that application. Instead, the entire policy is
contained in a single RPM.
After the previous discussions on default policies, it was clear that RPM
needs to support multiple policies and that a single label per file is not
sufficient. Several people suggested that modifying RPM to support multiple
labels per file would solve this problem. Concerns were voiced about placing
multiple labels in each package, however. It was argued that this would
enlarge the package size, perhaps substantially, without solving the
underlying problem of supporting multiple, arbitrary policies. This problem
has some similarities to translation strings in that a potentially large
number of translations needs to be provided for each package, they are not
necessarily known at package creation time, and it is desirable to upgrade
the translations without changing the packages. The translations are
supported by allowing RPM to query an external translation database at
installation time. There was a consensus that a similar scheme should be
adopted by RPM for file labels.
Policy Packaging and Dependencies
There was some discussion about the way policy is currently associated with
packages and how the dependency issues are solved. Fedora Core 2 provides a
single package with the entire policy for the system. Hardened Gentoo
provides a separate package for the policy for each application. The policy
packages are automatically installed by marking them as dependencies of the
application packages. The Gentoo package management system has a complex
infrastructure for optional dependencies to allow the installation of
different dependent packages based on user settings or system properties
(architecture for example). These optional dependencies allow for
considerable flexibility when managing SELinux policy packages.
Binary Policy Modules
The current work by Tresys on developing binary policy modules was
discussed. This will allow for the management of policies without source,
provide infrastructure and language support for specifying and tracking
dependencies, and optionally manage file labeling on the installation and
removal of policy modules. Some of the expected benefits of this work would
be the looser coupling between portions of the policy and simplified policy
management. For example, adding a user to the policy currently requires a
full policy development environment including the source for the entire
policy. The binary policy modules would allow the addition of a user without
source or policy development tools.
The desire to protect certain application by creating a separate domain for
each user domain in a system was brought up. This is currently accomplished
using macros that will be unavailable in the binary policy modules. It
suggested that this could be solved using inheritance. It was agreed to
investigate these additional policy language semantics.
User-space Object Managers
The need for better support of user-space object managers was discussed (see
"Security Enhanced X Status" for more discussion). In particular, it was
suggested that it is desirable to provide a mechanism that allows the policy
for user-space object managers to be selectively separated from each other
and the kernel policy. This is access control for policy modification and
can be implemented through namespace separation and creating an object
abstraction of the policy. Tresys stated that they are starting a research
project on this topic which will result in a user-mode policy server based
on the binary policy module work.
SECURITY ENHANCED X STATUS
A summary of the work done by the NSA to adapt user space SELinux type
controls to X windows was presented. This work involved two main tasks:
creating a user-space access vector cache and implementing the object
classes and access control within X. The user-space access vector cache has
been completed and is available as part of the standard NSA distribution.
The implementation is a port of the kernel access vector cache and includes
support for flushing on policy reload. The user-space cache is notified of
the policy reloads through a netlink socket.
The changes required to implement access control for X include the creation
of eleven new object classes and modifications to the X server. The new
object classes closely mirror those described in the technical report
"Securing The X Window System With SELinux" by NAI labs. It was reported
that the X developers are enthusiastic about the SELinux work and have
accepted the changes to the X server in a branch of the upstream CVS
repository. See http://www.x.org for more information.
NFS
A report on the progress of integrating SELinux mechanisms into NFS version
3 by the NSA was given. The current implementation was described as
relatively simple and experimental. In particular, the implementation does
not address many issues and has several assumptions including:
* the underlying security problems with NFS are not addressed,
* a secure network is assumed,
* the client and server must both have the same policy,
* and the issues with revocation caused by NFS caching are not
addressed.
Despite these issues, it is possible to have SELinux access control enforced
on NFS mounted file systems. This is done by extending the NFS protocol to
handle extended attributes so that a client can retrieve the labels of files
of NFS file systems and extending the client to enforce access based on
those labels. Additionally, mount options were added to specify that these
features should be used.
The current implementation is for NFS version 3, but it is expected that in
the future work will be done on NFS version 4. It is not clear whether the
NFS version 3 implementation will be acceptable upstream, but it is hoped
that the future work on NFS version 4 will be. The NFS version 3 patches are
available from the NSA website (http://www.nsa.gov/selinux). Finally, it was
mentioned that the NFS work has exposed several bugs related to the labeling
of sockets created by the kernel. Patches for these problems exist and were
merged into the 2.6.6 kernel.
TRAINING AND DOCUMENTATION
It was reported that there has recently been a large amount of new interest
expressed from both the corporate and government side for training. Tresys
is in the process of refreshing their SELinux course material and will be
offering a new set of classes shortly. The NSA is also working on updating
past reference papers to reflect the more recent generation of SELinux.
ASSURANCE
Assurance was mentioned several times throughout the symposium. No SELinux
system has currently been Common Criteria evaluated at any EAL level, though
it is expected that one of the distributions that is currently seeking
certification will have a system certified that includes SELinux. SELinux
cannot be evaluated separately; only a complete system can be evaluated.
BUSINESS CASE FOR SELINUX
There was a discussion of strategies for making a case for the use of
SELinux to decision makers in organizations. It was argued that making the
case to managers can be different than making a case to front-line technical
people. It was suggested that the fundamental question that needs to be
answered for managers is how does the technology solve an important problem
that they have.
19 years, 10 months
fedora policy changes
by Chris Grier
Hi, I'm using Fedora Core 2 with SELinux, and I was wondering if there
is an official place to submit (possible) policy changes. I have run
across a couple things that might need to be changed, and I would like
to submit them for the next versions of the policy packages. I can do
bugzilla if thats the right place for these things.
The main things I'm looking at right now are for dm-crypt. It seems that
there might not be correct labeling to support device mapper.
hda6 is the / partition, where the loopback file is (I'm using losetup
to setup the loop, and dm-crypt to encrypt, which is then mounted as a
user home directory)
audit(1086192065.154:0): avc: denied { read } for pid=2844
exe=/sbin/ldconfig name=libdevmapper.so.1.00 dev=hda6 ino=278879
scontext=root:sysadm_r:ldconfig_t tcontext=system_u:object_r:usr_t
tclass=file
audit(1086192065.179:0): avc: denied { read } for pid=2844
exe=/sbin/ldconfig name=libdevmapper.so dev=hda6 ino=278880
scontext=root:sysadm_r:ldconfig_t tcontext=system_u:object_r:usr_t
tclass=lnk_file
--
Chris Grier <grier(a)uiuc.edu>
19 years, 10 months
Access to the postgresql data files
by Igor Borisovsky
Hi.
I have a question about selinux policy configuration for FC2.
I need to forbid access to the postgresql data files from user root.
I guess i have to create certain type for postgresql. Let's name this type
pgsql.
Thus i have something like that:
[root@selinux pgsql]# pwd
/var/lib/pgsql
[root@selinux pgsql]# ls -aZ
drwx------+ postgres postgres postgres:object_r:pgsql_home_dir_t .
drwxr-xr-x root root system_u:object_r:var_lib_t ..
drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t backups
-rw------- postgres postgres postgres:object_r:pgsql_home_t .bash_history
-rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t .bash_profile
drwx------ postgres postgres postgres:object_r:pgsql_home_dir_t data
-rw-r--r-- postgres postgres postgres:object_r:pgsql_home_t initdb.i18n
drwxr-xr-x+ postgres postgres postgres:object_r:pgsql_home_t .mc
[root@selinux pgsql]#
So far user root within sysadm_r role has access to the postgresql data
files.
I guess i need to find and revoke this permission from sysadm_r role.
After looking at the policy.conf file I can't understand this.
So how can i prevent access to postgresql data files from user root?
Thanks.
19 years, 11 months
Re: Enabling SELinux (was Re: How to make SELinux in Fedora work?)
by Park Lee
On Thu, 03 Jun 2004 12:42:35 ,Daniel J Walsh wrote:
>No, Relabel will not work in a Non SELinux kernel.
But there are 2 items in The UnOfficial SELinux FAQ� http://www.crypt.gen.nz/selinux/faq.html :
I upgraded my SELinux kernel to a new version and now I get lots of errors on booting, what went wrong?
Bad things happen if you upgrade your kernel to a newer version which has an incompatible policy with the previous version. You probably forgot to install the policy and/or relabel the filesystems before booting the new version. Boot your system from a non-SELinux kernel and go back and do these things.
If one of those messages is "login[1007]: UNABLE TO GET VALID SID FOR root"
The SID table is mangled. Try logging in using a different method ( such as connecting over SSH ), otherwise you will need to recover by booting a non-SELinux kernel, then relabel the filesystem and reload the policy ( make reset and make load ).
Then, what are those means?
Does they mean that relabel can work in a non-SELinux kernel?
yours,
Park Lee
2004-06-03
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger
19 years, 11 months
Re: re:Enabling SELinux (was Re: How to make SELinux in Fedora work?)
by Park Lee
Dear sir,
Now, I know the reason to run 'fixfiles relabel' in single-user mode.
Let's look at the 3 steps again:
1. Modified /etc/sysconfig/selinux to have 'SELINUX=permissive'
2. Rebooted single-user and ran 'fixfiles relabel'
3. Rebooted multi-user
Can I take the steps in the order as the following:
1. Rebooted single-user and ran 'fixfiles relabel'
2. Rebooted multi-user
3. Modified /etc/sysconfig/selinux to have 'SELINUX=permissive'
4. Rebooted multi-user
That is ,can we first 'fixfiles relabel' in a non-SELinux kernel. and then turn into the SELinux kernel ? Is it safe?
Respectfully yours,
Park Lee
2004-06-03
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger
19 years, 11 months
re:Enabling SELinux (was Re: How to make SELinux in Fedora work?)
by Park Lee
ON Thu, 27 May 2004 11:07:33 ,Tom London wrote:
>Following the attached advice, here's what I did:
> 1. Modified /etc/sysconfig/selinux to have 'SELINUX=permissive'
> 2. Rebooted single-user and ran 'fixfiles relabel'
> 3. Rebooted multi-user
For the 2nd item, I want to ask why you must reboot in single-user? can't we run 'fixfiles relabel' directly?
Thank you
Park Lee
2004-06-03
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger
19 years, 11 months
No avc denied messages
by Richard Hally
When running kernel 406 in both enforcing and permissive mode with the
latest "strict" policy(1-13.2-3) there are no (absolutely none!) avc
denied messages. The troubling thing is that there is at least one thing
that works in permissive and fails in enforcing. The first thing I
checked was postgresql. It starts in permissive and fails to start in
enforcing and there are no avc denied messages in either case.
What could be the problem?
thanks for the help.
Richard Hally
19 years, 11 months
issue on 'fixfiles relabel'
by Park Lee
Hi,
I found in 'Fedora Core 2 SELinux FAQ', there is one item:
"Fedora Core ships with a new script fixfiles which supports three options: check, restore, and relabel. This allows users to relabel the file system without having the policy-sources package installed."
But ,if I don't install policy-sources package, where are the file_contexts information that used for relabelling?
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger
19 years, 11 months
Installing the new policy
by Richard Hally
Included below is the out put from doing a "yum install
selinux-policy\*" while in enforcing mode:
[root@old1 root]# yum install selinux-policy\*
Gathering header information file(s) from server(s)
Server: Fedora Core 2 - i386 - Base
Server: Fedora Core 2 - Development Tree
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Resolving dependencies
Dependencies resolved
I will do the following:
[install: selinux-policy-targeted 1.13.1-1.noarch]
[install: selinux-policy-strict 1.13.1-1.noarch]
[install: selinux-policy-strict-sources 1.13.1-1.noarch]
[install: selinux-policy-targeted-sources 1.13.1-1.noarch]
Is this ok [y/N]: y
Downloading Packages
Getting selinux-policy-targeted-1.13.1-1.noarch.rpm
selinux-policy-targeted-1 100% |=========================| 25 kB 00:00
Getting selinux-policy-strict-1.13.1-1.noarch.rpm
selinux-policy-strict-1.1 100% |=========================| 1.1 MB 00:08
Getting selinux-policy-strict-sources-1.13.1-1.noarch.rpm
selinux-policy-strict-sou 100% |=========================| 1.3 MB 00:12
Getting selinux-policy-targeted-sources-1.13.1-1.noarch.rpm
selinux-policy-targeted-s 100% |=========================| 252 kB 00:01
Running test transaction:
Test transaction complete, Success!
selinux-policy-strict 100 % done 1/6
Can't open '/etc/selinux/strict/policy/policy.17': Permission denied
selinux-policy-targeted 100 % done 2/6
Can't open '/etc/selinux/targeted/policy/policy.17': Permission denied
selinux-policy-strict-sources 100 % done 3/6
make: Entering directory `/etc/selinux/strict/src/policy'
/usr/sbin/load_policy /etc/selinux/strict/policy/policy.`cat
/selinux/policyvers`
Can't open '/etc/selinux/strict/policy/policy.17': Permission denied
make: *** [tmp/load] Error 2
make: Leaving directory `/etc/selinux/strict/src/policy'
selinux-policy-targeted-sources 100 % done 4/6
make: Entering directory `/etc/selinux/targeted/src/policy'
/usr/sbin/load_policy /etc/selinux/targeted/policy/policy.`cat
/selinux/policyvers`
Can't open '/etc/selinux/targeted/policy/policy.17': Permission denied
make: *** [tmp/load] Error 2
make: Leaving directory `/etc/selinux/targeted/src/policy'
warning: /etc/security/selinux/policy.17 saved as
/etc/security/selinux/policy.17.rpmsave
warning: /etc/security/selinux/file_contexts saved as
/etc/security/selinux/file_contexts.rpmsave
Erasing: policy 5/6
warning: /etc/security/selinux/src/policy/users saved as
/etc/security/selinux/src/policy/users.rpmsave
warning:
/etc/security/selinux/src/policy/file_contexts/program/seuser.fc saved
as /etc/security/selinux/src/policy/file_contexts/program/seuser.fc.rpmsave
Erasing: policy-sources 6/6
Installed: selinux-policy-targeted 1.13.1-1.noarch
selinux-policy-strict 1.13.1-1.noarch selinux-policy-strict-sources
1.13.1-1.noarch selinux-policy-targeted-sources 1.13.1-1.noarch
Transaction(s) Complete
[root@old1 root]#
Richard Hally
19 years, 11 months
