What is SELinux targeted policy?
by Daniel J Walsh
When FC2 was released we attempted to add the NSA strict policy to the
operating system.
We were able to find hundreds of problems in the policy and we quickly
found out that users
who customized their environments in unexpected ways caused SELinux and
the OS to conflict.
We decided at that point to take a step back and go with a strategy
where we would lock down
a few daemons with SELinux and allow the rest of the system to run in
the same manner with
or without SELinux. Targeted policy was born.
In targeted policy most processes run in a unconfined_t domain, which
means for the most part they
are not being confined by the SELinux policy. They are still governed
by Standard unix security, but
not effected by SELinux. Certain network daemons have policy and the
unconfined_t policy transitions
to those policies when the application starts. So when the system boots
init runs in the unconfined_t policy,
but when named starts up it transitions to the named_t domain and is
locked down. We use the following
policies
nscd.te apache.te dhcpd.te named.te ntpd.te portmap.te snmpd.te
squid.te syslogd.te
Also users can select which daemons he want to have SELinux to protect
via system-config-securitylevel.
So if an admin finds that SELinux will not allow his apache web server
to run the way he wants he can
turn off the transition. This will drop it back to normal Unix
protections, but all other daemons will continue
to be protected by SELinux. Through the use of these "boolean" values
the admin can increase or decrease the
level of protection SELinux provides.
In the future we plan on adding additional Domains that SELinux will
protect.
Strict policy is still available but will be not be installable
directly, you can use selinux-config-securitylevel to turn it on
and relabel the file system.
Dan
19 years, 7 months
please try SELinux again
by Colin Walters
Hi,
Talking with a number of people at the office, it seems a high
percentage of Fedora developers disabled SELinux during FC2 test2, which
was our first attempt at SELinux. Many other users and testers in the
Fedora community likely did so as well.
I think a lot of people are not aware that things have changed (and
generally improved) dramatically since then.
Instead of the original "strict" policy which covered everything, a new
"targeted" policy has been developed which only applies SELinux
restrictions to a few select system daemons. Regular user login
sessions are unrestricted.
This targeted policy will be enabled by default for FC3. But those of
you who are upgrading from existing systems, if you earlier added
selinux=0 to your grub config, or disabled it in /etc/sysconfig/selinux,
will not be testing the new policy.
Please: undo those changes, and give it another try. Be sure
that /etc/sysconfig/selinux has these two lines:
SELINUX=enforcing
SELINUXTYPE=targeted
Also be sure you don't have selinux=0 in your grub configuration.
19 years, 7 months
Wireless update to ifup and network-functions
by Jon Nettleton
If have put together a function and some new code for
is_wireless_device that uses iwlist to scan available access points
and then ifup a new configuration file if it finds one matching
ifcfg-DEVICE_ESSID. My questions are.
1) Is this the correct list?
2) Is this something that maintainers are interested in adding?
3) What is prefered format for patches?
Hope to help out making Fedora Core 3 the best it can be.
-Jon
19 years, 7 months
Re: "Stateless Linux" project
by Bryan K. Wright
Hi folks,
The stateless project is a great idea. Thanks for pursuing this.
One concern, though: the pdf overview says:
"No question that work remains. However, a categorical policy going forward is
that we expect an office productivity worker to be able to use all their
hardware without the root password, and without touching the command line.
We will consider it a bug if desktop-class hardware requires
either root or opening a terminal."
This sounds fine, but please don't REQUIRE a graphical interface
to use the hardware. I have lots of researchers who ssh into group servers
and use USB disks, shared tape drives, printers, etc.
On another topic, the overview notes that disaster recovery for
laptops requires that the laptop home directory be backed up often --
"perhaps whenever the laptop connects to the intranet". Toward this end,
will the stateless project incorporate support for network block devices?
A local disk in a "RAID 1" array with a remote block device sounds like
a good way to ensure that an up-to-date remote copy of files is maintained
while the user is connected. When the connection is broken, the remote
half of the mirror would be unavailable, and the local disk would be used.
On reconnection, the halves of the mirror would resync.
Thanks,
Bryan
--
===============================================================================
Bryan Wright |"If you take cranberries and stew them like
Physics Department | applesauce, they taste much more like prunes
University of Virginia | than rhubarb does." -- Groucho
Charlottesville, VA 22901 |
(434) 924-7218 | bryan(a)virginia.edu
===============================================================================
19 years, 7 months
[usclug-chat] cyrus-imapd causes hardlock?
by Eric Hattemer
Is it possible for cyrus and postfix to cause a hardlock when no other
programs seem to? 1-10 minutes after I start my mail server, the system
hardlocks. I can record and transcode gigabytes of tv shows, run a web
server, download and upload tons of stuff, and test the system in any
way with no problems. Windows has no problems. Yet when I start cyrus,
postfix, and saslauthd, the system indexes the mail for a while, then
dies. Anyone ever hear of this before? I don't understand it. There's
no kernel modules or special syscalls a mail server program runs, right?
This is fedora development (2.90) with kernel 2.6.8-1.541 with latest
cyrus-imapd, saslauthd, and postfix. I want to figure out whether I
should file a bug report, since this almost doesn't make sense...
-Eric Hattemer
19 years, 7 months
Probably a given - but udev-030-26 made my system unbootable (detailed)
by Mark Mielke
The first error was "Warning: unable to find a console" or something to that
effect. The boot process paused. I manually created:
crw------- 1 root root 5, 1 Sep 17 22:18 console
Then, it complained about /dev/null not being writable. Sure enough,
/dev/null was a regular file with bytes in it. *sigh* Created that as:
crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null
No luck. Booting still had major trouble. Finally I gave up:
To get myself back into working order - I renamed /dev to /dev.udev
and copied a working /dev from another partition to /dev. It looks
like a lot of things are missing from /dev.udev. The current contents
of /dev.udev is (after I added console and null):
$ ls -l /dev.udev
total 6
lrwxr-xr-x 1 root root 8 Dec 1 2003 cdrom -> /dev/hdc
crw------- 1 root root 5, 1 Sep 17 22:18 console
crw------- 1 root root 10, 63 Jul 31 09:16 device-mapper
crw-rw---- 1 root root 14, 9 Aug 21 00:05 dmmidi
prw------- 1 root root 0 Sep 17 22:07 initctl|
crw-r----- 1 root kmem 1, 2 Aug 28 14:13 kmem
drwxr-xr-x 2 root root 2048 Jul 31 10:55 mapper/
crw------- 1 root root 14, 2 Aug 21 00:05 midi
lrwxr-xr-x 1 root root 5 Dec 1 2003 mouse -> psaux
crw-rw-rw- 1 root root 1, 3 Feb 23 2004 null
crw-rw---- 1 mark root 195, 0 Jul 1 13:57 nvidia0
crw------- 1 mark root 195, 1 Jul 1 13:57 nvidia1
crw------- 1 mark root 195, 2 Jul 1 13:57 nvidia2
crw------- 1 mark root 195, 3 Jul 1 13:57 nvidia3
crw------- 1 mark root 195, 4 Jul 1 13:57 nvidia4
crw------- 1 mark root 195, 5 Jul 1 13:57 nvidia5
crw------- 1 mark root 195, 6 Jul 1 13:57 nvidia6
crw------- 1 mark root 195, 7 Jul 1 13:57 nvidia7
crw-rw---- 1 mark root 195, 255 Jul 1 13:57 nvidiactl
lrwxr-xr-x 1 root root 20 Dec 1 2003 ptal-printd -> /var/run/ptal-printd/
drwxr-xr-x 2 root root 2048 Jul 4 2002 pts/
drwxr-xr-x 2 root root 2048 Sep 6 2001 shm/
crw-rw---- 1 root tty 4, 32 Aug 24 15:47 tty32
crw-rw---- 1 root tty 4, 33 Aug 24 15:47 tty33
crw-rw---- 1 root tty 4, 34 Aug 24 15:47 tty34
crw-rw---- 1 root tty 4, 35 Aug 24 15:47 tty35
crw-rw---- 1 root tty 4, 36 Aug 24 15:47 tty36
crw-rw---- 1 root tty 4, 37 Aug 24 15:47 tty37
crw-rw---- 1 root tty 4, 38 Aug 24 15:47 tty38
crw-rw---- 1 root tty 4, 39 Aug 24 15:47 tty39
crw-rw---- 1 root tty 4, 40 Aug 24 15:47 tty40
crw-rw---- 1 root tty 4, 41 Aug 24 15:47 tty41
crw-rw---- 1 root tty 4, 42 Aug 24 15:47 tty42
crw-rw---- 1 root tty 4, 43 Aug 24 15:47 tty43
crw-rw---- 1 root tty 4, 44 Aug 24 15:47 tty44
crw-rw---- 1 root tty 4, 45 Aug 24 15:47 tty45
crw-rw---- 1 root tty 4, 46 Aug 24 15:47 tty46
crw-rw---- 1 root tty 4, 47 Aug 24 15:47 tty47
crw-rw---- 1 root tty 4, 48 Aug 24 15:47 tty48
crw-rw---- 1 root tty 4, 49 Aug 24 15:47 tty49
crw-rw---- 1 root tty 4, 50 Aug 24 15:47 tty50
crw-rw---- 1 root tty 4, 51 Aug 24 15:47 tty51
crw-rw---- 1 root tty 4, 52 Aug 24 15:47 tty52
crw-rw---- 1 root tty 4, 53 Aug 24 15:47 tty53
crw-rw---- 1 root tty 4, 54 Aug 24 15:47 tty54
crw-rw---- 1 root tty 4, 55 Aug 24 15:47 tty55
crw-rw---- 1 root tty 4, 56 Aug 24 15:47 tty56
crw-rw---- 1 root tty 4, 57 Aug 24 15:47 tty57
crw-rw---- 1 root tty 4, 58 Aug 24 15:47 tty58
crw-rw---- 1 root tty 4, 59 Aug 24 15:47 tty59
crw-rw---- 1 root tty 4, 60 Aug 24 15:47 tty60
crw-rw---- 1 root tty 4, 61 Aug 24 15:47 tty61
crw-rw---- 1 root tty 4, 62 Aug 24 15:47 tty62
crw-rw---- 1 root tty 4, 63 Aug 24 15:47 tty63
lrwxrwxrwx 1 root root 4 Aug 28 14:44 XOR -> null
Hope this helps somebody in debugging this! :-)
mark
--
mark@mielke.cc/markm@ncf.ca/markm(a)nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
19 years, 7 months