summaryrefslogtreecommitdiff
path: root/README
blob: 19818688cda9612427f46ce23333ee441824e832 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
BUILDING THE XACE-SELINUX BRANCH


1. Set up your Build Host

You need the following packages installed beforehand.  This list is from a
Fedora box; install the equivalent for other distros if you're not using
Fedora.  The ccache package is not strictly necessary but speeds up compile
times significantly.

gcc
ccache
automake
autoconf
imake
flex
bison
libtool
zlib-devel
xmlto
tetex
docbook-dtds
xml-common
openjade
freetype-devel
fontconfig-devel
expat-devel
gcc-c++
libpng-devel
ncurses-devel
audit-libs-devel
openssl-devel
graphviz
hal-devel

In addition, you need a very recent version of libselinux installed.  You
could try the libselinux-devel package, but I compile and install libselinux
directly from the Sourceforge SVN upstream.

It does not matter if your build host already has an X desktop installed on
it.  In fact, you'll probably want this so you can test the SELinux-enabled
X server by running the desktop applications on it.  The build scripts will
install the new X server into /usr/local or another path that you choose, so
nothing will conflict.

Finally, you will probably need a second machine that you can use to ssh into
your development machine, since when the X server crashes it's usually not
possible to get back to the console.


2. Decide where you will Build From and Install To

On my development machine I keep all the X code in $HOME/git and build
it there, and install to /usr/local.  I set the ownership of /usr/local
to be owned by myself, so I don't need to be root to install things there.

The scripts will assume this setup by default.  If you wish to change it you
can do so (as described in step 4) but make sure the install directory is
writable by you.

IMPORTANT: Make sure that your /etc/ld.so.conf configuration has the install
directory in it so that it takes preference over the system libraries!  You
need this so that the new X server doesn't try and link with the wrong
libraries.  Add /usr/local to the files, and run ldconfig as root.


3. Unzip the Tarball

Change to your home directory (or wherever) and unzip the tarball.  This will
create the git/ directory with various subdirectories and files inside.  This
is where all the X source code will be stored.


4. Update preferences

Edit the file do_common.pm and change the settings under CONFIGURATION as
desired.  You can change the options to the configure scripts by editing
the hash values in this section.  You may want to turn off some of the
unneeded stuff in the xserver config options; I have them enabled for
testing purposes.


5. Download the source

Change into the git directory and run "./do_fetch.pl".  This will go out and
checkout all the sources from upstream (you obviously need Internet access
to do this).  If you get any "Operation failed" errors, e-mail me.  This
will take a while since there are so many separate modules.

The script will also take care of switching to the XACE-SELINUX branch.

Note that not all of the upstream source is downloaded.  None of the sample
applications are downloaded, and only a basic set of drivers.


6. Build the source

Change into the git directory and run "./do_build.pl all".  This will
build and install everything.  The compile output goes in build.log in
the git directory.  If you get any errors, e-mail me.  This will take a good
long while.

The argument to the do_build.pl script is a target for building.  The
targets are defined in the file do_build.conf.  Each target consists
of a list of modules to build.  In particular, the "serverclean" and
"serveronly" targets will rebuild just the server, and the "drivers"
target will rebuild just the drivers.  If you want to know more about
the format of this file/how to add more targets, etc., e-mail me.

NOTE: the drivers have an ABI dependency on the X Server.  Since the SELinux
work has broken the ABI, this means that you can't use the drivers that
came with the Linux distro, you must use the ones compiled from source!  It
should "just work" so that the X server looks for drivers in the right place,
but if it doesn't the symptom will be a segfaulting X server.


7. Build the SELinux policy

This can be found in the "xselinux" branch of refpolicy on the Tresys
OSS site.  Instead of checking out "trunk" checkout "branches/xselinux".

Build and load this policy.  It should work in either strict or targeted.
Note that the xserver binary, /usr/local/bin/Xorg or whatever, needs to
be labeled with xserver_exec_t, and some other special labels are defined
in the xwindows.fc file_contexts that should be set properly.


8. Configure the X Server

The /etc/X11/xorg.conf file should be edited to match your system.  I have
tested with the simple "keyboard" and "mouse" drivers and the "vesa" video
driver.  

You can edit the gdm configuration so that it starts the new X server instead
of the system one.  To do this, edit /etc/gdm/custom.conf and add these lines
after the "[server]" line:

[server-Standard]
name=Standard server
command=/usr/local/bin/Xorg -audit 4
flexible=true

To change back, just replace the "command" line to point to the normal server.

You can also configure startx/xinit to launch a different server.  Check the
manpages for these commands.


9. Run the X Server

The server should start and run.  Right now, AVC's are logged on the stderr
of the X server as well as the log file Xorg.0.log.  On my system the X 
server writes to /usr/local/var/log instead of /var/log, not sure if this
is compiled-in behavior.

In enforcing mode, things will probably break royally.  The policy is still
under development and apps typically do not handle errors from the X server
gracefully.


10. Updating and rebuilding

To update your sources from upstream, change into the git directory and
run "./do_update.pl all".  Again the argument to the script is a target, this
time defined in do_update.conf, which defines which packages to update.

Then go back up and run the do_build.pl script as described earlier.

Again if you get any errors, e-mail me.