/etc/hal/capability.d/printer_update.hal
by Tom London
Notice the following:
Sep 9 09:37:55 fedora kernel: audit(1094747875.090:0): avc: denied
{ execute } for pid=3131 exe=/usr/sbin/hald name=printer_update.hal
dev=hda2 ino=280646 scontext=system_u:system_r:hald_t
tcontext=system_u:object_r:etc_t tclass=file
Sep 9 09:37:55 fedora kernel: audit(1094747875.090:0): avc: denied
{ execute } for pid=3131 exe=/usr/sbin/hald name=printer_update.hal
dev=hda2 ino=280646 scontext=system_u:system_r:hald_t
tcontext=system_u:object_r:etc_t tclass=file
Should the following be added to hald.fc?
/etc/hal/capability.d/printer_update.hal -- system_u:object_r:hald_exec_t
(similar to /etc/hal/device.d/printer_remove.hal ?)
tom
--
Tom London
19 years, 7 months
relabeling cycles...
by Tom London
No matter how often I 'fix' these files with either setfiles or fixfiles,
they seem to revert back the next reboot. I think I've also booted
single-user to do relabeling with the same effect.
Not clear this affects functioning in any way.
tom
> /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux.accept from
> system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t
> /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux from
> system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t
> /usr/sbin/setfiles: relabeling /tmp/.X11-unix from
> system_u:object_r:xdm_tmp_t
> to system_u:object_r:xdm_xserver_tmp_t
> /usr/sbin/setfiles: relabeling /tmp/.X0-lock from
> system_u:object_r:xdm_xserver_tmp_t to system_u:object_r:xdm_tmp_t
19 years, 7 months
latest Rawhide... selinux-policy-strict-1.17.9-2
by Tom London
Newest Rawhide packages improve things a bit for strict/enforcing, but
still no joy.
When booting strict/enforcing, the system seems to boot to single user mode,
but is unable to write to the console. Last messages are avc denials from
/bin/dmesg, that seem to occur just before the 'Welcome to Fedora' message.
I can hear the device discovery going on, but nothing on the console.
After about 5 minutes, ALT-CTL-DEL brought the system down, with the
customary console messages. (But, error messages about most file systems
not being mounted).
Here are the early avcs...
Sep 3 07:25:35 fedora kernel: audit(1094196259.050:0): avc: denied {
create } for pid=1 exe=/sbin/init name=initctl
scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t
tclass=fifo_file
Sep 3 07:25:36 fedora smartd[2856]: Opened configuration file
/etc/smartd.conf
Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied {
associate } for pid=1 exe=/sbin/init name=initctl
scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t
tclass=filesystem
Sep 3 07:25:36 fedora smartd[2856]: Configuration file /etc/smartd.conf
parsed.
Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied {
read write } for pid=1 exe=/sbin/init name=initctl dev=tmpfs ino=2095
scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t
tclass=fifo_file
Sep 3 07:25:36 fedora smartd[2856]: Device: /dev/hda, opened
Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied {
getattr } for pid=1 exe=/sbin/init path=/dev/initctl dev=tmpfs ino=2095
scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t
tclass=fifo_file
Sep 3 07:25:36 fedora smartd[2856]: Device: /dev/hda, found in smartd
database.
Sep 3 07:25:36 fedora kernel: audit(1094196259.312:0): avc: denied {
read write } for pid=344 exe=/bin/hostname name=console dev=tmpfs
ino=864 scontext=system_u:system_r:hostname_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:36 fedora kernel: audit(1094196259.382:0): avc: denied {
search } for pid=346 exe=/bin/bash dev=tmpfs ino=863
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:unlabeled_t
tclass=dir
Sep 3 07:25:36 fedora kernel: audit(1094196259.382:0): avc: denied {
read write } for pid=346 exe=/bin/bash name=tty dev=tmpfs ino=1227
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:unlabeled_t
tclass=chr_file
Sep 3 07:25:37 fedora smartd[2856]: Device: /dev/hda, is SMART capable.
Adding to "monitor" list.
Sep 3 07:25:37 fedora kernel: audit(1094196260.276:0): avc: denied {
read write } for pid=490 exe=/bin/mount name=console dev=tmpfs ino=864
scontext=system_u:system_r:mount_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:37 fedora smartd[2856]: Monitoring 1 ATA and 0 SCSI devices
Sep 3 07:25:37 fedora kernel: audit(1094196260.277:0): avc: denied {
search } for pid=490 exe=/bin/mount dev=tmpfs ino=863
scontext=system_u:system_r:mount_t
tcontext=system_u:object_r:unlabeled_t tclass=dir
Sep 3 07:25:37 fedora kernel: SELinux: initialized (dev usbfs, type
usbfs), uses genfs_contexts
Sep 3 07:25:38 fedora smartd[2858]: smartd has fork()ed into background
mode. New PID=2858.
Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied {
read write } for pid=514 exe=/sbin/consoletype name=console dev=tmpfs
ino=864 scontext=system_u:system_r:consoletype_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:38 fedora smartd: smartd startup succeeded
Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied {
getattr } for pid=514 exe=/sbin/consoletype path=/dev/console dev=tmpfs
ino=864 scontext=system_u:system_r:consoletype_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied {
ioctl } for pid=514 exe=/sbin/consoletype path=/dev/console dev=tmpfs
ino=864 scontext=system_u:system_r:consoletype_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied {
read write } for pid=724 exe=/sbin/minilogd name=console dev=tmpfs
ino=864 scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied {
use } for pid=724 exe=/sbin/minilogd path=/init dev=rootfs ino=17
scontext=system_u:system_r:syslogd_t tcontext=system_u:system_r:kernel_t
tclass=fd
Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied {
read } for pid=724 exe=/sbin/minilogd path=/init dev=rootfs ino=17
scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:root_t
tclass=file
Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied {
search } for pid=724 exe=/sbin/minilogd dev=tmpfs ino=863
scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:unlabeled_t tclass=dir
Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied {
write } for pid=724 exe=/sbin/minilogd dev=tmpfs ino=863
scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:unlabeled_t tclass=dir
Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied {
add_name } for pid=724 exe=/sbin/minilogd name=log
scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:unlabeled_t tclass=dir
Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied {
create } for pid=724 exe=/sbin/minilogd name=log
scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:unlabeled_t tclass=sock_file
Sep 3 07:25:38 fedora kernel: audit(1094196262.160:0): avc: denied {
getattr } for pid=727 exe=/sbin/minilogd path=/dev/log dev=tmpfs
ino=2641 scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:unlabeled_t tclass=sock_file
Sep 3 07:25:38 fedora kernel: audit(1094196262.217:0): avc: denied {
read write } for pid=730 exe=/bin/dmesg name=console dev=tmpfs ino=864
scontext=system_u:system_r:dmesg_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:38 fedora acpid: acpid startup succeeded
Sep 3 07:25:38 fedora kernel: audit(1094196262.285:0): avc: denied {
read write } for pid=735 exe=/sbin/restorecon name=console dev=tmpfs
ino=864 scontext=system_u:system_r:restorecon_t
tcontext=system_u:object_r:unlabeled_t tclass=chr_file
Sep 3 07:25:38 fedora kernel: audit(1094196266.948:0): avc: denied {
create } for pid=746 exe=/sbin/udev name=input
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t
tclass=dir
tom
19 years, 7 months
[idea] udev + selinux
by Nigel Kukard
Just an idea, but why not have udev set the context on its root path?
I have a simplistic patch for this if its a good idea.
Regards
Nigel Kukard
19 years, 7 months
RE: Users writting to home directory
by Don Patterson
> ----- Original Message -----
> From: "James R. Marcus" <jmarcus(a)mvalent.net>
> To: "Stephen Smalley" <sds(a)epoch.ncsc.mil>
> Cc: <selinux(a)tycho.nsa.gov>
> Sent: Tuesday, August 24, 2004 2:14 PM
> Subject: RE: Users writting to home directory
>
>
> > Okay I tried just creating a user under home. While in permissive
> > mode they can login to the ftp server and upload and download.
> > However when I turn on enforced mode they get this message:
> >
> > C:\Documents and Settings\jmarcus\Desktop>ftp ftp Connected to
> > ftp.mvalent.local.
> > 220 Welcome to mValent, Inc. FTP service.
> > User (ftp.mvalent.local:(none)): jmarcus7
> > 331 Please specify the password.
> > Password:
> > 500 OOPS: cannot change directory:/home/jmarcus7 500 OOPS: child
> > died Connection closed by remote host.
> >
> > C:\Documents and Settings\jmarcus\Desktop>
> >
> > ftp policy # seuseradd -g users -d /home/jmarcus7 -m -s /bin/bash
> > -c "James R. Marcus" jmarcus7 loading new policy...
> >
> > Error relabeling users home directory files: User is not defined in
> > the policy.
> >
>
In case anyone sees a similar problem, this bug was fixed in setools 1.4.x.
To upgrade use the commands:
Fedora - 'yum update setools'
Gentoo - 'emerge setools'
Don Patterson
Tresys Technology
www.tresys.com
19 years, 7 months
(no subject)
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
Re: fedora-selinux-list Digest, Vol 7, Issue 1
by Stanley A. Klein
On Wed, 2004-09-01 at 12:00, Linas Vepstas <linas(a)austin.ibm.com> wrote:
>
> Every now and then, I look at SELinux, and I get scared away by its
> complexity. This complexity makes it very hard to audit, and assure
> oneself that its actually providing any real security, as opposed to
> the illusion of security. During this email thread, there are
> references to mysterious rules that neither party in the conversation
> fully understands; this scares me.
>
This is not the first time I've heard about SELinux complexity. A
colleague attended a meeting of the DC area SELinux Users Group and came
away repeating stories about 50000 rules that needed to be defined for a
typical system. His reaction was "How can you be sure you have done
50000 rules right?". I heard similar talk in the hallway at one of the
EGOVOS conferences.
I think the complexity derives from Mandatory Access Control rather than
SELinux itself. Thus far almost all of the attention regarding SELinux
policies has been given to basic computer infrastructure and basic
system administration. Some of the packages in the basic infrastructure
have hundreds of files. MAC requires each file in each package to be
considered and its access control rules defined. The complexity in the
rules is a consequence of the complexity in the infrastructure.
The real issue is the adequacy of tools to manage the complexity.
Furthermore, although SELinux has the mechanisms for defining and
enforcing access control rules beyond the basic infrastructure, trying
to develop policies based on business process rules and business
considerations looks like a daunting task right now. By this I mean
roles that get beyond sysadmin and user into areas such as bank teller
or hospital primary care provider or control system operations shift
supervisor, together with the rules appropriate to those roles in their
business contexts.
I think there are people working on tool concepts, but it seems we are a
few years away from taming the complexity of MAC and SELinux
sufficiently to allow users to easily and confidently define SELinux
policies for applications based on business considerations.
Stan Klein
--
Stanley A. Klein, D.Sc.
Principal Consultant
Stan Klein Associates, LLC
301-881-4087
19 years, 7 months
Re: log file names (was Additional rule files)
by Russell Coker
On Sat, 4 Sep 2004 11:12, Erich Schubert <erich(a)debian.org> wrote:
> The next two rule sets are for the statistic tools "bindgraph" and
> "mailgraph". The first parses bind query logs and does nice graphs out
> of them, the second does the same for postfix+amavis logs.
Do we need to have two different domains for programs that do the same thing?
Both bindgraph and mailgraph can read the same file types as input and their
output can be accessed by cgi-bin scripts. It seems that there is little (if
any) benefit in isolating them.
If we were to assign different types to different log files (may require code
changes in syslogd) then we could deny the mailgraph program the ability to
read log files other than mail.log and deny the bindgraph program the ability
to read mail.log.
Also note that in your policy both those programs can read /var/log/auth.log
(Debian) and /var/log/secure (Fedora). This is not desirable, we probably
should make changes to the syslog setup.
One possible change is greater use of sub-directories in /var/log. We could
have /var/log/security/ for auth.log, secure, and any other security critical
log files and /var/log/mail/ for mail server log files (including POP server,
and maybe webmail), etc. Doing this would allow different types for the log
files with no code changes to syslogd, and this would make it more beneficial
to have separate domains for mailgraph and bindgraph.
I've CC'd this to fedora-selinux and debian-devel because if we make such
changes then we want to get some cross-distribution agreement on file names.
--
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, 7 months
Wiped installation - 541 kernel - SELinux cleared?
by Jim Cornette
After viewing the logs myself, I think that SELinux was working
properly. I deleted the installation and am using it as a clean download
partition for the FC3T2 iso files.
It looks like SELInux is working pretty decent up until gawk, the latest
kernel, etc:
Jim
--
You're at the end of the road again.
19 years, 7 months