Something is causing checkpolicy to segfault. I ended up building
it from the .src.rpm so it was compiled with -g and not stripped.
checkpolicy-1.27.1-1, libselinux-1.26-6, updated to -devel tree as of this morning.
gdb then says:
(gdb) run -M -o policy.20 policy.conf
Starting program: /usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy -M -o policy.20 policy.conf
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xffffe000
/usr/src/redhat/BUILD/checkpolicy-1.27.1/checkpolicy: loading policy configuration from policy.conf
Program received signal SIGSEGV, Segmentation fault.
parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc)
3569 range_start = range_end = cdatum->value - 1;
#0 parse_categories (id=0x8bbff28 "s0", levdatum=0x80a75b8, cats=0x80a00bc)
#1 0x0804f340 in parse_security_context (c=0x80a00ac) at policy_parse.y:3850
#2 0x080534f2 in yyparse () at policy_parse.y:3925
#3 0x0804a743 in main (argc=5, argv=0xbfeecd74) at checkpolicy.c:549
This ring any bells? Have I dorked up a file ('users' most likely) during the
conversion to MCS in a way that didn't flag a syntax error but causes a crash?
Hints, etc accepted..
I have a FC4 system, kernel: 2.6.12-1.1447_FC4, selinux targeted, enforced,
If I setenforce 0, then users can log in squirrelmail and read/send emails w/o
problems. If I setenforce 1, then users cannot login sm. The error message
Error connecting to IMAP server: localhost.
13 : Permission denied
However, the system log does not show error message about it. So, if I run
the selinux command, I got:
# audit2allow -l -i /var/log/messages -o
# make load
make: Nothing to be done for `load'.
BTW, users can still run pine to read/send emails. I tried to set
squirrelmail's server setting using sendmail or smtp, but no help.
Can somebody tell how to solve the problem?
By popular request, the deadline for paper submissions for the 2006
SELinux Symposium has been extended to October 1, 2005. See the
symposium web site (www.selinux-symposium.org) for the call for papers
and submissions requirements.
SELinux Symposium Chair
I can't find where I read this now, could somebody please tell me what I
need to add/remove from the strict policy to disallow running of the
setenforce command (but still allow changing enforcement mode via
A question for you, Which are the benefits/advantages regarding
execute these specific services: sshd, samba, postgres and vsftpd over
a system platform Selinux-enabled, instead of execute those mentioned
services over a system platform SELinux-disabled??
Thanks and Rgds.
Ma. Alejandra Castillo M.
Tonights rawhide update for selinux-policy-targeted and selinux-policy-strict include MCS.
What is MCS?
Multi-category Security (MCS) is a discretionary labeling mechanism for
SELinux. It allows users to add meaningful security labels to their own
files. Only domains with access to these labels will then be able to
access the files. Examples of category labels are "Company Confidential",
"Intranet Only" and "Patient Records".
MCS can only further restrict access to files, after Unix DAC rules and
SELinux MAC Type Enforcement rules have been applied. MCS uses much of the
Multi-level Security (MLS) technology present in SELinux, but is designed
to be simpler and map more readily to general use.
The general idea is to provide end users with more control over the
security of their own files and help make SELinux more user-oriented. In
the future, we expect to make use of category labels in areas such as
labeled printing, where the category label is printed on each page.
A reboot is required to turn on the MLS/MCS field on policy. The goal was to allow everything
to continue working without the reboot. A relabel should not be necessary.
In the current Fedora spec file, libselinux has libsetrans as a prereq,
thereby pulling it in on libselinux updates for all users regardless of
policy. However, libsetrans presumes that MCS is enabled and always
appends :s0 to contexts when converting to raw format if they lack it.
This breaks (for example) a system running strict policy, as libselinux
then starts using the MCS-specific libsetrans and it starts
appending :so to raw contexts, but the kernel then rejects those
contexts since it does not have a MLS-enabled policy.
libsetrans is supposed to be optional, with libselinux gracefully
falling back to no translation if it is absent. I can possibly see
making it a dependency of MCS-enabled targeted policy packages, but not
of libselinux. Yes?
National Security Agency
Running targeted/enforcing, latest rawhide.
Today's updates broke lots. Booting hangs with many messages about
'invalid type' from file-contexts, etc.
Anyone seeing this or did I break something?