AVCs with ntpd
by Felipe Alfaro Solana
OK, so I'm trying SElinux after having it disabled for some time.
That's what I did:
1. Installed selinux-policy-targeted-1.17.16-2
2. Recompiled the kernel with SElinux support
3. Booted into single user mode
4. Ran "fixfiles relabel"
5. Rebooted with "selinux=1"
Now, I'm seeing a lot of these:
audit(1095681913.039:0(: avc: denied { search } for pid=2515
exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t
tcontext=user_u:object_r"tmpfs_t tclass=dir
The problem here is that I'm using UDEV and that the initial ramdisk
mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" that
resides on disk.
How should I fix this?
19 years, 7 months
More AVCs during boot
by Felipe Alfaro Solana
Hi!
With selinux-policy-targeted, I get this during boot:
audit(1095721178.335:0): avc: denied { associate } for pid=508
exe=/sbin/restorecon name=initctl dev=tmpfs ino=1992
scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t
tclass=filesystem
audit(1095721179.084:0): avc: denied { associate } for pid=721
exe=/usr/sbin/setfiles name=initctl dev=tmpfs ino=1992
scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t
tclass=filesystem
which seem related related to "/dev/initctl".
audit(1095721179.097:0): avc: denied { associate } for pid=721
exe=/usr/sbin/setfiles name=.udev.tdb dev=tmpfs ino=366
scontext=system_u:object_r:udev_tbl_t
tcontext=system_u:object_r:tmpfs_t tclass=filesystem
which is related to /dev/.udev.tdb
audit(1095714008.289:0): avc: denied { setrlimit } for pid=2218
exe=/usr/sbin/named scontext=user_u:system_r:named_t
tcontext=user_u:system_r:named_t tclass=process
related to bind
audit(1095714008.771:0): avc: denied { read } for pid=2251
exe=/usr/sbin/ntpd name=drift dev=hda2 ino=10289214
scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t
tclass=file
related to ntpd.
Any ideas?
19 years, 7 months
SELinux Symposium Call for Presentation Proposals
by Frank Mayer
CALL FOR PRESENTATION PROPOSALS
FIRST SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org)
The inaugural symposium on Security Enhanced Linux (SELinux) will be held March
2-4 2005 in the Silver Spring, Maryland, USA (near Washington, DC). SELinux
brings the power of flexible mandatory access control such as type enforcement
to Linux. The symposium is an opportunity to learn about SELinux and share
technical and application experiences.
The call for presentation and tutorial proposals is now open until October 1,
2004. All proposals will be reviewed by the review committees for inclusion in
the symposium agenda. To submit proposals visit
http://www.selinux-symposium.org.
19 years, 7 months
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
Variable naming confusion
by Bob Gustafson
To me, there is a lot of confusion in the naming and choice of values of
the SELINUX booleans. (Maybe I just don't have my head around the
concepts.. - but I don't think I am alone)
For example:
The variable 'SELINUX' in the file /etc/selinux/config has the value
choices 'enforcing' or 'permissive'.
The variable 'enforce' in the /boot/grub/grub.conf file has the value
choices '=0' or '=1'
The variable shown by the command 'getenforce' is either 'Permissive' or
'Enforcing' (note the initial capitalization)
When using the runtime command 'setenforce', the argument is either '0'
or '1'
When using the script command 'selinuxenabled', the result is '0' if it
IS enabled.
Suggestions
The variable 'SELINUX' is either 'enabled' or 'disabled'
The variable 'enforcing' is either 'enabled' or 'disabled'
(This can be named 'enforce' rather than 'enforcing' - would help when
trying to remember whether the runtime command is 'setenforce' or
'setenforcing')
The variable 'SELINUXTYPE' is 'strict', 'targeted', 'myownpolicy',
'strangleddaemons', etc.
19 years, 7 months
Bug 129584: restrictions on user_t
by Ivan Gyurdiev
Bug link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129584
> Additional Comment #9 From Daniel Walsh (dwalsh(a)redhat.com) on
> 2004-09-15 15:55
> Yes there are a lot of files that user can not access. Mainly any
> file that has a security context associated with it and doesn't have
> the attribute usercanread.
> Again I want to bring this conversation to the public list and come to
> concensus. We can add usercanread to these files, but the question
> than is should a user be able to read all files even if they are world
> readable.
I don't see why not. If you think the user should not be able
to read those files, then why aren't their permissions flags
set accordingly? If a file was intended to be readable only
by a certain application or only by root then it could have had
the proper user/group/rwx flags set - this restriction could
have been imposed without SELinux. If it is marked
user readable then it seems to me that any user should
be able to read it (or at least that there are no
security reasons to deny it). So why
does SElinux impose restrictions on user_t
that contradict this explicit setting?
--
Ivan Gyurdiev <ivg2(a)cornell.edu>
Cornell University
19 years, 7 months
lsusb
by Tom London
Running strict/enforcing, latest Rawhide packages including latest
from Dan's tree (selinux-policy-strict-1.17.18-2).
Running 'lsusb' as root fails, but '/sbin/lsusb' as user works.
[root@fedora ~]# lsusb
cannot open /proc/bus/usb, Permission denied (13)
Works in permissive mode. Here are the avc's from permissive mode:
Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied
{ read } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335
scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t
tclass=dir
Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied
{ getattr } for pid=13020 exe=/sbin/lsusb path=/proc/bus/usb
dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t
tcontext=system_u:object_r:usbfs_t tclass=dir
Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied
{ search } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335
scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t
tclass=dir
Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied
{ read } for pid=13020 exe=/sbin/lsusb name=001 dev=usbfs ino=6351
scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t
tclass=file
These look like:
r_dir_file(sysadm_t, usbfs_t)
r_dir_file($1_t, usbfs_t) is in user_macros.te.
Should it be in base_user_macros.te? Included in admin_macros.te?
tom
--
Tom London
19 years, 7 months
Re: please try SELinux again
by Colin Walters
On Sat, 2004-09-18 at 23:19 +0200, Lars wrote:
>
> when i try to enable selinux it only boots to the message
> "setting up local disks" in rhgb and stays there.
Hmm. Are you running the latest rawhide? Does it work again when you
add enforcing=0 to the boot line?
[We should move this discussion to fedora-selinux-list]
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
Boolean utilities segv's
by George C. Wilson
Hi,
We found what appears to be a bug in libselinux. The getsebool, setsebool,
and togglesebool all SIGSEGV when SELINUX=disabled.
The global that stores the selinuxfs mountpoint in libselinux, selinux_mnt, is
initialized to NULL. selinuxfs is not mounted when SELinux is disabled,
therefore no mountpoint exists when init_selinuxmnt() scans /proc/mounts, and
selinux_mnt remains NULL. So when get_bool_value() in booleans.c attempts to
strlen(selinux_mnt), a SIGSEGV results. The fix is to validate selinux_mnt
before the offending strlen() in get_bool_value(), line 101 of booleans.c from
selinux-usr-2004081908. It probably would not hurt to validate name as well.
The same bug exists in FC3.
Thanks
--
George Wilson <ltcgcw(a)us.ibm.com>
IBM Linux Technology Center
19 years, 7 months
