User file access auditing
by Barry Roomberg
I have setup a Fedora 2 box with SELinux enabled.
I'm able to add users and relabel /home to allow their .ssh keys to
work, so I have a baseline install that is working.
I would like to create a shared dir tree that certain users have full
access to. Every file access that reads or writes data (stat, open,
read, write, delete, rename, ???) should be logged, while still allowing
the operation to complete.
Is SELinux appropriate for that type of tracking?
If so, can anyone give me a hint on the way to construct the policy?
Thanks.
Barry
19 years, 6 months
SELinux and the Desktop
by Jerry Haltom
Howdy. I really have nothing at all to do with Fedora, don't use it.
Never even seen it. However, you seem to be the only group interested
in SELinux for the masses, so I'm going to lay out an idea I've had.
SELinux has a place on the desktop.
Currently, a large piece is missing from the desktop security
landscape. User's can receive, by email or IM, executable files. These
can be in the form of actual real binaries, pseudo-binaries (flash), or
script languages (javascript, html, etc). Up to now the current
attitude has been "don't open files you don't trust, don't go to
websites you don't trust, don't run scripts you don't trust". This
"rule" ignores one common principle. USERS DONT CARE! It doesn't matter
that they SHOULDN"T open an executable their friend or co-worker sends
them, they will anyways. Is this so bad? I don't think so.
So here's where SELinux comes in. SELinux allows the system to place
restrictions on executable programs beyond that offered by the user
identity itself. It allows you to audit, and deny syscall execution,
which is every programs interface to the world.
So why can't one program place SELinux policy's on other software? Why
can't a desktop interface listen for faults in SELinux, change those
policy's based on the user's actions or requests, and let the program
continue, at runtime?
Consider the following example:
Bob receives an executable from his co-worker Joe. Bob opens it from
his email. His email client sets up a policy restricting all access to
everything, except maybe /tmp, and the obvious, the program runs. Oh
no! It's a virus! The program attempts to establish a connection to
Bob's address book (exposed by evolution data server). SELinux detects
the programs attempts to open a socket that it was not allowed to do.
The program blocks on the syscall. SELinux is configured to continue
blocking the program until told otherwise. SELinux locates a D-BUS
daemon for Bob and notifies it about the security event. Running as Bob
is sec-policy-daemon which is listening to D-BUS for fault
notifications. This daemon reads the information Bob's email client
attached to the process. The information reads as follows:
1) don't allow the program to do anything except read/write to /tmp
2) do allow the program to open outgoing ports after notifying the user
The daemon realizes that the action isn't allowed, but that it could be
allowed if the user consents to it, so the daemon pops up on the user's
desktop a nice dialog box, "The application Blah has attempted to
access the file /tmp/contact-socket (or whatever). Do you want to allow
this action?" Most likely t his dialog would ask for the user's
password again. Upon receiving a "Yes", SELinux would be instructed to
allow the program to access the socket. If the user presses Yes, the
process ceases being blocked, and goes on. In the case of No, the
process will probably die. ;0
Of course this policy would be configurable. In some offices admins
would probably not want the user to even have the option to open
outgoing ports from downloaded software, they just don't wnat to take
the risk. In some home circumstances, it might be a little bit looser.
It's up to you.
What this does is let users do what they will do anyways: run the
program. You won't stop them, I won't stop them, and we probably
shouldn't. We should make it so they CAN without risk to their systems.
Do enjoy. I hope you guys do something with this. It's what we need.
Jerry Haltom
wasabi(a)larvalstage.net
19 years, 6 months
SELinux Testing Software/Scripts
by Alex Ackerman
This may sound like an odd request, but I am currently working on my
master's thesis on the topic of SELinux integration into the workplace.
Part of the analysis involves testing the security containment
capabilities of SELinux; i.e., making sure that SELinux functions as
advertised when dealing with events of escalating privilege. Does anyone
on this list have any recommendations on scripts or programs which can
test these capabilities? My test platforms are Fedora Core 3 (once
released) and Red Hat Enterprise Linux v4.0 Beta 1. My current thinking
would be to downgrade certain packages (httpd, etc) to a known
vulnerable state and test, but would like to know how the members on the
list test their systems. Any help would be appreciated. I can be
reached at ackermal at jmu dot edu or alex at darkhonor dot com if you
would like to discuss this off-list. Thank you for any assistance.
Alex Ackerman
James Madison University
19 years, 6 months
udev strangeness with latest rawhide
by Russell Coker
Running the latest rawhide I get AVC messages indicating that /bin/udev
(not /sbin/udev) is running in kernel_t during the early stages of system
boot.
/bin/udev is the file name used in the initrd! So it seems that after the SE
Linux policy is loaded (IE after /sbin/init has been run from the main root
fs) there is still a copy of udev from the initrd being run. This seems to
be a bug in initrd that could lead to inconsistent behaviour. I'm not sure
how this comes about (and of course apart from SE Linux messages in the
kernel message log all the evidence is gone by the time the system is ready
to login).
Any suggestions on how to debug this?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
19 years, 6 months
Kernel Panic on upgrading libselinux
by Jaspreet Singh
Hi,
I wanted to write my own security policies so i upgraded to packages
given shipped with FC3 ( libselinux , policy-targeted, policycoreutils ,
SysVinit and checkpolicy)
When i tried to reboot (to 2.6.5-1.358 default with FC2) with
SELINUX=enforcing and SELINUXTYPE=targeted .. it says -
kernel panic ...
No policy loaded ?????????
i tried booting to kernel 2.6.8-1.386 .. it booted fine ...
Then i also tried to run "fixfiles relabel" and rebooted same problem.
also booting with SELINUX=permissive gives the following errors on "ls
-Z"
Option only possible with selinux enabled kernels ???????
Any clues ???
Jaspreet :-(
19 years, 6 months
prelink and yum conflict
by Tom London
If prelink is running from cron when you do a 'yum install' of a package
that want's to do a ldconfig, you get the following avc
Oct 8 08:31:39 fedora kernel: audit(1097249499.123:0): avc: denied
{ read } for pid=14475 exe=/lib/ld-2.3.3.so name=ld.so.cache dev=hda2
ino=4473477 scontext=system_u:system_r:prelink_t
tcontext=root:object_r:etc_t tclass=file
and a message from ldconfig complaining about not being able to
link ld.so.cache~
I believe (hope?!) that this is harmless. But, does it make sense
to prevent this, say by creating a lock files that would be used to
prevent prelink and ldconfig from colliding?
Or is it safe to allow this access? A 'dontaudit' would still
leave curious looking messages during the yum.
tom
--
Tom London
19 years, 6 months
Try my experimental rsync with xattr support
by Jay Fenlason
I've written a patch to rsync that adds support for transferring posix
extended attributes. I've put the srpm and an i386 binary rpm at
http://people.redhat.com/fenlason/rsync/rsync-2.6.3-2.{src,i386}.rpm
These rpms also contain the acl patch.
To enable the transfer of extended attributes you need to use the new
-X option. Naturally, both the client and server rsyncs must include
the extended attribute patch if you use -X.
Please try this rpm out, and report whether it works or not. After I
get some feedback I'll be sending the patch (or its successor) to the
upstream rsync maintainer.
-- JF
19 years, 6 months
User policy problem with strict policy
by James Morris
I'm using the latest fedora strict policy sources, and have noticed that
the generated policy.conf file is lacking generated policy entries for
extra users.
I added myself to the users file:
# sample for regular user
user jmorris roles { user_r };
compiled policy:
# make policy.conf
But the only entry related to the user is the one I added in the users
file:
# grep jmorris policy.conf
user jmorris roles { user_r };
Have I missed a step or is something wrong in the policy compilation
process?
- James
--
James Morris
<jmorris(a)redhat.com>
19 years, 6 months
