As promised, an answer to SELinux in a separate thread.
On the other hand, something that's been a big adjustment - SELinux in
redhat 5. It seems like none of the vendors out there support running
under SELinux. For example, for both our monitoring product and
backup
solution I've had to craft custom SELinux policy exceptions.
I don't really blame Redhat for this, but I'm pissed as all h*** at
the
vendors. Follow me on this as I descend into ranting for the rest of
this post, or perhaps not, to preserve your sanity :-)
I'm pretty keen on hearing more about this. While switching your
system
into Strict or MLS mode _will unquestionably break things_, leaving it
in the stock Targeted mode shouldn't be to much of a hassle. What apps
did you run into problems with?
I'm not a Zed user, but I do manage a few Linux systems. On one, I like
to symlink into an ISO image to get it mounted view autofs.
The idea was to loop-mount the ISO image when I want to do an http
install.
Here is one example line from my /etc/auto.misc:
fc5 -fstype=iso9660,ro,nosuid,nodev,noexec,loop
:/var/local/mirrors/linux/Fedora/5/i386/ISO/FC-5-i386-DVD.iso
I serve from a directory under /var/local/mirrors, and it had been my
practice to symlink the install tree like this:
/var/local/mirrors/linux/CentOS/5.1/os/i386 -> /misc/C5
Unfortunately, I've not been able ti divine the magic incantation to get
it mounted and accessible to Apache.
The system's adequately isolated from the ungodly, but the only way I
have to make this work is to turn selinux off, and this irks.
I'll start a new thread to answer this question & provide a detailed
answer. I'm opposed to thread jacking this and turning it into a
SELinux conversation, as I'm sure there may be more questions ;)
This gets us into a little of MAC vs DAC theory. Under historical
models privilege is granted based upon user/group settings. For
example, say I have the following:
1) Apache is installed as user apache, group _system_ (yes, this
actually is common!)
2) My DNS configuration file is owned by DNSUser, and _grouped to system_.
*Problem: * If my web-facing Apache instance gets hacked, the attacker
inherit Apaches group rights to "system". My DNS configuration file is
grouped to "system." Apache gets hacked, and they now can potentially
change my DNS configuration file.
*Answer: *We introduce the concept of "security labels" via SELinux.
Everything in Linux is ultimately a file -- from devices, processes, to
actual data -- and thus we can create a new access model. With SELinux,
our scenario looks more like:
1) Apache is installed as user apache, group system. Data that Apache
should read is labeled as "httpd_t"
2) DNS is installed as user DNSUser, group system. Data that Bind
should read is labeled as "named_t"
Apache gets hacked, and the DNS configuration file has a different
security label. Access will be denied, as Apache doesn't have access to
"named_t"
Under your setup, I'd suspect your /var/local directories get labeled as
"var_t", which Apache may not have access to. To troubleshoot this, we
have a few options, in increasing complexity:
1) Put a blind fold on, wonder into a dark cave, and hope we don't
fall. i.e. disable SELinux. Not ideal.
2) Disable SELinux protections _for the specific data type getting denied
_3) Create your own policy
I use Fedora on my laptop. Things in Fedora often break, causing me to
fix them on the fly. In my case I have the most issues with VPN
settings. (For those of you who were at my talk at zExpo, remember how
my network didn't work?)
All SELinux errors will go into /var/log/messages. A typical VPN error
message for me is:
/var/log/messages:
type=SYSCALL msg=audit(1204719775.306:738): arch=40000003 syscall=54
success=no exit=19 a0=4 a1=8933 a2=bfcec1bc a3=bfcec1bc items=0
ppid=3900 pid=5003 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) comm="ip" exe="/sbin/ip"
subj=user_u:system_r:ifconfig_t:s0 key=(null)
_*So, what do I know?*_
1) AVC Event ID 738
2) syscall=54 (I'd have to google this)
3) root (or an application on its behalf) was
running /sbin/ip
4) context = user_u:system_r:ifconfig_t:s0
_*What are my options?*_
*1) Disabling SELinux*
Obviously not idea. It turns off *all* protections.
*2) Disable SELinux Protetions _for the specific data type getting denied._
*A little known fact is that you can target which part of SELinux to
turn off. I often have issues with my VPN configuration, and to fix
them rapidly I turn off checking for the ifconfig_t. It's not ideal,
but it *is* better than turning off SELinux as a whole.
To do this, type
# semanage permissive -a ifconfig_t
*3) Create your own Policy*_*
*_This isn't as hard as it used to be (NOTE: Use RHEL5!). We currently
ship a tool called "audit2allow," which will create the policy template
for you. In *my* case I see that the audit ID is 738:
audit(1204719775.306:_*738*_)
# ausearch -a 738 | audit2allow -M ShawnsVPNFix
# semodule -i ShawnsVPNFix
Done.
man ausearch & audit2allow for more info. There's a good article about
this @
http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/
In your case you can take a look at your audit log and see what part of
SELinux you need to disable. Alternatively you can create your own
policy, which isn't that hard these days.
SELinux is just a new security model that many people aren't familiar
with, and takes some getting used to. Hope this helps!
Note that I do give fairly frequent SELinux talks at conferences, the
next of which will be at SHARE in Austin.
-Shawn
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
