new Fedora user asks help
by Pietro R.A. Binetti
hello everyone,
i am a new user of Fedora core 2, and a newer of linux-like OS as well.
2 days ago i installed Fedora on my notebook: acer travel mate 212T.
i already have some problems that i can't solve:
1) Can't change the Screen resolution
when i installed the OS, my screen hadn't been recognized, so i chose
"generic LCD monitor" with a resolution of 800x600.
once installed, i changed my mind and i wanted to switch into 1024x768
(supported by my hardware, for sure).
to do that, i opened the Display window, from System Settings menu icon.
here i configured a generic LCD panel with 1024x768 resolution from the
Hardware folder and rebooted the PC. then, in the display window i had
the possibility to choose the wanted resolution. doing that and
rebooting i can see 1024x768 as the selected screen resolution, but
looking at the screen things haven't changed: i always have the old
800x600.
what should i do?
2)Touch pad
the touch pad of my pc is correctly working, even if the click must be
done pressing the left button and can't be done with the "touch". i
can't find where i can configure or change the settings of my touch pad.
can i?
thanks in advance for your help.
regards,
Pietro
19 years, 8 months
cupsd locking up system during boot - targeted mode
by Jim Cornette
I just joined up to the list because I just enabled SELinux.
The first thing that I did was to boot up the system in permissive mode,
strict policy and into runlevel 1. I then ran fixfiles relabel at the
prompt.
I then changed /etc/sysconfig/selinux to reflect enforcing and use the
targeted policy.
Anyway, I ended up recieving the repeated error below. I posted to the
test list and was guided to this list as more appropriate.
This error looped and kept printing to the screen until I finally hit
the ctl-alt-del key to reboot the system. I then came back into the
system using selinux=0 when the grub prompt was presented.
Aug 17 21:01:59 cornette-fc2 kernel: audit(1092790919.215:0): avc:
denied { associate } for pid=3665 exe=/usr/sbin/cupsd name=0
scontext=user_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t
tclass=filesystem
I had avc errors recorded in the /var/log/messages using the strict and
targeted policies. I'll submit them later through bugzilla.
Jim
19 years, 8 months
udev leaking files/file-descriptors...
by t l
Running strict enforcing off of Rawhide, udev is
still leaking fds across execs, especially
execs of /sbin/restorecon.
Here is an example avc showing the leak:
Aug 14 19:35:38 fedora kernel: audit(1092537300.503:0): avc: denied { read write } for pid=1214 exe=/sbin/restorecon path=socket:[1188] dev=sockfs ino=1188 scontext=system_u:system_r:restorecon_t tcontext=system_u:system_r:udev_t tclass=unix_dgram_socket
Probing a bit (and using Russell's suggestion to 'wrap' /sbin/restorecon), I figured
out that udev is still 'leaking' open files across the exec of
/etc/dev.d/default/selinux.dev. [udev is not calling
fcntl(fd, F_SETFD, FD_CLOEXEC) .]
I'll bugzilla this here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130100
but here is a patch to /etc/dev.d/default/selinux.dev
that closes enough (all?) of the problematic file descriptors before
exec-ing /sbin/restorecon.
tom
--- selinux.dev 2004-08-15 08:58:13.000000000 -0700
+++ /etc/dev.d/default/selinux.dev 2004-08-14 20:19:12.000000000 -0700
@@ -10,5 +10,5 @@
if [ "$UDEV_LOG" = "yes" -a -x /usr/bin/logger ]; then
/usr/bin/logger -t selinux.dev -p auth.debug "Restoring file security contexts for $DEVNAME"
fi
- /sbin/restorecon $DEVNAME 4<&-
+ /sbin/restorecon $DEVNAME 3<&- 4<&- 5<&- 6<&-
fi
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
19 years, 9 months
kernel file handle leak?
by Russell Coker
When I boot a laptop with a Cardbus Ethernet card installed I get the
following avc messages related to a kernel file handle. Is this a known
issue?
(1092707493.572:0): avc: denied { read write } for pid=2131 exe=/sbin/ip
path=socket:[921] dev=sockfs ino=921 scontext=system_u:system_r:ifconfig_t
tcontext=system_u:system_r:kernel_t tclass=unix_dgram_socket
audit(1092707493.581:0): avc: denied { read write } for pid=2133
exe=/sbin/iwconfig path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707493.591:0): avc: denied { read write } for pid=2135
exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707493.604:0): avc: denied { read write } for pid=2139
exe=/sbin/modprobe path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:insmod_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707493.634:0): avc: denied { read write } for pid=2141
exe=/sbin/ip path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707493.641:0): avc: denied { read write } for pid=2143
exe=/sbin/dhclient path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:dhcpc_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707498.179:0): avc: denied { read write } for pid=2316
exe=/sbin/ip path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707498.188:0): avc: denied { read write } for pid=2318
exe=/sbin/ethtool path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707498.195:0): avc: denied { read write } for pid=2320
exe=/sbin/ip path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707498.265:0): avc: denied { read write } for pid=2331
exe=/sbin/ifconfig path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707499.315:0): avc: denied { read write } for pid=2402
exe=/sbin/ip path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
audit(1092707499.369:0): avc: denied { read write } for pid=2409
exe=/sbin/ip path=socket:[921] dev=sockfs ino=921
scontext=system_u:system_r:ifconfig_t tcontext=system_u:system_r:kernel_t
tclass=unix_dgram_socket
--
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, 9 months
Snort and sysadm_devpts
by Business DSL User
Hey all,
I'm trying to run Snort 2.1.3 under Fedora Core 2, with SELinux. When I
restart Snort, it dies after logging the message "pcap_loop: recvfrom:
Socket operation on non-socket." When I put SELinux in permissive mode,
Snort works fine. So, I know the problem is with my SELinux policy
configuration. Thing is, SELinux doesn't log any AVC messages explaining
Snort's death.
As an experiment, I deleted the dontaudit rules from policy.conf, and built
and loaded the modified policy. The resulting AVC messages identified about
a half dozen operations that were failing. One of them seems to be
responsible for killing Snort. Adding the rule:
allow snort_t sysadm_devpts_t:chr_file { read write };
enables Snort to restart just fine.
Some questions arise:
1. Is the technique of deleting dontaudit rules valid, or is there a better
way?
2. Is there possibly a better policy tweak that would permit Snort to
restart okay? I'm not cheerful about giving Snort access to the console.
3. What's with Snort trying to access /dev/pts? Seems to me that a
daemonized program shouldn't do that. So, there's obviously something I
don't know.
Thanks,
19 years, 9 months
some fixes to allow user roles in targeted policy
by Colin Walters
Hi,
I'm trying to create a restricted user domain with the targeted policy,
e.g.:
full_user_role(test)
This turned up quite a number of issues.
First, I had to suck in user.te from the strict policy to get the
booleans. I stripped it down to just the essentials; it may make sense
to add some of it back.
Secondly, unconfined_t isn't completely unconfined; in particular it
can't transition to arbitrary domains. So sshd (which runs as
unconfined_t) can't enter the new user domain. So I added a bit to
full_user_role which allows unconfined_t to transition to new user
domains (via a shell) in the targeted policy.
Third, there were a few missing ifdefs (likely applicable in strict
policy too).
Fourth, the user domain needs access to user_home_dir_t:dir.
The fifth issue is access to /dev/pts. The comment above the patch
should explain things. Is there a better solution here?
19 years, 9 months
encrypted root fs
by Russell Coker
As an experiment I setup a machine with an encrypted root fs.
I have attached the patch for mkinitrd which I used. It is hard-coded for the
device names that I use (/dev/V0/fc2enc for the encrypted LVM volume) because
I couldn't think of a good way of storing this.
For production use this would need a --encrypt-root option or maybe reading
some sort of /etc/crypttab file and deducing that root encryption is needed.
Also with my patch you need to put "--with=dm-crypt --with=aes" on the
mkinitrd command-line.
To create the encrypted device you have to run
"cryptsetup -d /etc/root-key create crypto /dev/V0/fc2enc" to create the
encrypted device and then dd a file system of the same size
to /dev/mapper/crypto.
Finally I've created a statically linked version of cryptsetup for use in the
initrd and named it /usr/bin/cryptsetup.static . I've put the binary on
http://www.coker.com.au/crypt/ as a temporary measure for anyone who wants to
play with it. I'll release my code patches once I get them tidied up a bit.
Currently the statically linked version of cryptsetup is 780K in size. The
libdevmapper code drags in libselinux code which makes it overly large. I
think that perhaps we need to have a statically linked version of the
libdevmapper code without SE Linux support for use in the initrd (the SE
Linux policy is loaded by /sbin/init so there is no possibility of doing any
useful SE Linux stuff from inside the initrd).
I notice that /bin/lvm in the initrd (/sbin/lvm.static on the root fs) is over
1M in size and includes SE Linux code that is of no use in the initrd. Is
the statically linked version of lvm used for anything other than the initrd?
If not then we should just build it with no SE Linux support because once
again it can't do anything productive with SE Linux code in the initrd and it
just wastes space.
Please let me know what you think of these ideas. I would like to get some
feedback before I start filing bugzilla reports.
Finally please don't even think of testing this out on any machine that
contains important data. There are lots of ways that this can go wrong and
lose your data.
The aim of this work is to have a system that boots from removable media and
uses encryption for all block devices so that if it is stolen no data will be
lost and so someone who gets temporary access to the hardware will have a
much more difficult time of trying to crack it.
--
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, 9 months
rssh policy for fedora
by Colin Walters
Hi,
I've ported my rssh policy to the FC2 strict policy; it required some
changes to allow sshd to enter the domain (the "userdomain" attribute),
and to make pty labeling work correctly (can_create_pty and
type_change). I'm a little unsure about making this domain be a
userdomain, there are a lot of implications from that. But I think it
was the constraints that were stopping sshd from entering it.
It probably doesn't make sense to include this in the Fedora policy at
the moment since we don't ship rssh in Fedora, but maybe others here
will find this useful.
Although, come to think of it, this approach would probably be a good
way to restrict cvs+ssh too, which is a fairly common setup.
19 years, 9 months
Re: crond/mailman, .... Rawhide issues....[FIX?]
by t l
These changes seem to make crond/mailman happy:
allow system_crond_t mailman_lock_t:dir rw_dir_perms;
allow system_crond_t mailman_lock_t:file create_file_perms;
allow system_crond_t mailman_log_t:file { append read };
tom
* From: Tom London <selinux comcast net>
Latest stuff from Rawhide: crond/mailman issues again....
Here is the email (I got lots of these!):
Subject: Cron <mailman fedora> /usr/bin/python -S /var/mailman/cron/gate_news
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/mailman>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=mailman>
X-Cron-Env: <USER=mailman>
Traceback (most recent call last):
File "/var/mailman/cron/gate_news", line 284, in ?
main()
File "/var/mailman/cron/gate_news", line 259, in main
lock.lock(timeout=0.5)
File "/var/mailman/Mailman/LockFile.py", line 243, in lock
self.__write()
File "/var/mailman/Mailman/LockFile.py", line 422, in __write
fp = open(self.__tmpfname, 'w')
IOError: [Errno 13] Permission denied: '/var/mailman/locks/gate_news.lock.fedora.XXX.3986.0'
Here are the AVCs:
Aug 13 08:35:01 fedora crond(pam_unix)[4065]: session opened for user mailman by (uid=0)
Aug 13 08:35:01 fedora crond(pam_unix)[4068]: session opened for user root by (uid=0)
Aug 13 08:35:02 fedora kernel: audit(1092411302.395:0): avc: denied { read append } for pid=4067 exe=/usr/bin/python name=error dev=hda2 ino=442471 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:mailman_log_t tclass=file
Aug 13 08:35:02 fedora kernel: audit(1092411302.397:0): avc: denied { write } for pid=4067 exe=/usr/bin/python name=locks dev=hda2 ino=442718 scontext=system_u:system_r:system_crond_t tcontext=system_u:object_r:mailman_lock_t tclass=dir
Aug 13 08:35:02 fedora crond(pam_unix)[4068]: session closed for user root
Aug 13 08:35:04 fedora crond(pam_unix)[4065]: session closed for user mailman
audit2allow produces:
allow system_crond_t mailman_lock_t:dir { write };
allow system_crond_t mailman_log_t:file { append read };
That right, (or have I broken something else)?
tom
[BTW, booleans now get loaded. Neat!]
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
19 years, 9 months
Preliminary Announce: First SELinux Symposium
by Frank Mayer
Preliminary Announcement
FIRST SECURITY ENHANCED LINUX SYMPOSIUM
The inaugural symposium on Security Enhanced Linux (SELinux) is being
planned for March 2005 in the Washington, D.C., USA area. SELinux
brings the power of type enforcement (TE), a flexible mandatory access
control mechanism, to Linux. This announcement is to make the
community aware of the preliminary plans for the symposium, and
solicit interests in participation. The symposium will be an
opportunity to learn about SELinux and share technical and application
experiences.
The tentative format for the symposium is a 3-day conference, with one
day for tutorials and two days for technical presentations and
interchange. Those interested in submitting presentation or tutorial
proposals may do so at sel-symposium(a)tresys.com. Topics of interest
include:
+ History and design of SELinux
+ Use and application of TE Enforcement in securing systems
+ TE policy development and analysis
+ Use and Configuration of MLS and RBAC in securing systems
+ Updates on the various Linux distributions using SELinux
+ Practical "root"-less system administration policies
+ Example system solutions using SELinux, case studies
+ On-going and planed enhancements to SELinux
+ On-going research and development activities
+ Tools and products supporting/using SELinux
+ Security evaluation and certification issues
+ Tutorials
The exact dates, location, and cost of the symposium are to be
determined. Future information will be posted in the following web
site: www.tresys.com/selinux/symposium
The organizing committees for the symposium are as follows:
Technical Committee:
Joshua Brindle, Tresys
Russell Coker, Red Hat
Chad Hanson, TCS
Howard Holm, NSA
Trent Jaeger, IBM
Karl MacMillan, Tresys
Frank Mayer, Tresys
James Morris, Red Hat
Ed Reed, Novell
Doc Shankar, IBM
Stephen Smalley, NSA
Daniel Walsh, Red Hat
Tutorial Committee:
David Caplan, Tresys
Howard Holm, NSA
Karl MacMillan, Tresys
19 years, 9 months
