acpid avcs
by Steve G
Hi...from my logs:
type=PATH msg=audit(12/23/2005 10:36:04.030:20507) : item=0 name=(null)
inode=14909846 dev=03:07 mode=socket,666 ouid=root ogid=root rdev=00:00
obj=system_u:object_r:var_run_t:s0
type=SOCKADDR msg=audit(12/23/2005 10:36:04.030:20507) : saddr=local
/var/run/acpid.socket
type=SYSCALL msg=audit(12/23/2005 10:36:04.030:20507) : arch=x86_64
syscall=connect success=no exit=-13(Permission denied) a0=4 a1=7fffffbf25c0
a2=6e a3=7fffffbf2428 items=1 pid=2242 auid=unknown(4294967295) uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
comm=hald-addon-acpi exe=/usr/libexec/hald-addon-acpi
subj=system_u:system_r:hald_t:s0
type=AVC msg=audit(12/23/2005 10:36:04.030:20507) : avc: denied { write }
for pid=2242 comm=hald-addon-acpi name=acpid.socket dev=hda7 ino=14909846
scontext=system_u:system_r:hald_t:s0 context=system_u:object_r:var_run_t:s0
tclass=sock_file
This just scrolls for hours and hours...
-Steve
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
18 years, 4 months
sendmail+greylist-milter problem
by Alexey Tarasov
Greetings,
Sorry, if same matters was discussed previously - I've not found any
trails. If there is any FAQ with solution of my problem, please give me
a link.
Thanks for help.
best regards,
Alexey Tarasov
---------------
Problem 1.
Installed: sendmail-8.3.14, milter-greylist-2.0.2,
selinux-policy-targeted-1.27.2-19
starting sendmail from init results in:
maillog
---
sendmail[1997]: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1674:
Xgreylist: local socket name /var/milter-greylist/milter-greylist.sock
unsafe: Permission denied
---
audit.log:
---
type=AVC msg=audit(1135060778.168:5): avc: denied { getattr } for
pid=1994 comm="newaliases" name="milter-greylist.sock" dev=dm-0
ino=7831655 scontext=system_u:system_r:sendmail_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1135060778.168:5): arch=40000003 syscall=196
success=no exit=-13 a0=bfd5995c a1=bfd598ac a2=b7c60ff4 a3=bfd598ac
items=1 pid=1994 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=51 sgid=51 fsgid=51 comm="newaliases" exe="/usr/sbin/sendmail.sendmail"
type=AVC_PATH msg=audit(1135060778.168:5):
path="/var/milter-greylist/milter-greylist.sock"
type=PATH msg=audit(1135060778.168:5): item=0
name="/var/milter-greylist/milter-greylist.sock" flags=0 inode=7831655
dev=fd:00 mode=0140755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1135060778.260:6): avc: denied { getattr } for
pid=1997 comm="sendmail" name="milter-greylist.sock" dev=dm-0
ino=7831655 scontext=system_u:system_r:sendmail_t:s0
tcontext=system_u:object_r:var_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1135060778.260:6): arch=40000003 syscall=196
success=no exit=-13 a0=bf89508c a1=bf894fdc a2=b7c9dff4 a3=bf894fdc
items=1 pid=1997 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=51 sgid=51 fsgid=51 comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
type=AVC_PATH msg=audit(1135060778.260:6):
path="/var/milter-greylist/milter-greylist.sock"
type=PATH msg=audit(1135060778.260:6): item=0
name="/var/milter-greylist/milter-greylist.sock" flags=0 inode=7831655
dev=fd:00 mode=0140755 ouid=0 ogid=0 rdev=00:00
---
And this output is generated on system shutdown:
---
type=AVC msg=audit(1135059155.814:79): avc: denied { getattr } for
pid=3857 comm="K30sendmail" name="sendmail.pid" dev=dm-0 ino=7602305
scontext=system_u:system_r:sendmail_launch_t:s0
tcontext=root:object_r:var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1135059155.814:79): arch=40000003 syscall=195
success=no exit=-13 a0=8113cf8 a1=bfe421c8 a2=aedff4 a3=8113828 items=1
pid=3857 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="K30sendmail" exe="/bin/bash"
type=AVC_PATH msg=audit(1135059155.814:79): path="/var/run/sendmail.pid"
type=PATH msg=audit(1135059155.814:79): item=0
name="/var/run/sendmail.pid" flags=1 inode=7602305 dev=fd:00
mode=0100600 ouid=0 ogid=51 rdev=00:00
type=AVC msg=audit(1135059155.822:80): avc: denied { unlink } for
pid=3864 comm="rm" name="sendmail.pid" dev=dm-0 ino=7602305
scontext=system_u:system_r:sendmail_launch_t:s0
tcontext=root:object_r:var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1135059155.822:80): arch=40000003 syscall=10
success=no exit=-13 a0=bfdabf03 a1=1 a2=8050204 a3=bfdab9e0 items=1
pid=3864 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="rm" exe="/bin/rm"
type=PATH msg=audit(1135059155.822:80): item=0
name="/var/run/sendmail.pid" flags=10 inode=7602212 dev=fd:00
mode=040755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1135059155.826:81): avc: denied { unlink } for
pid=3865 comm="rm" name="sendmail" dev=dm-0 ino=7602307
scontext=system_u:system_r:sendmail_launch_t:s0
tcontext=root:object_r:var_lock_t:s0 tclass=file
type=SYSCALL msg=audit(1135059155.826:81): arch=40000003 syscall=10
success=no exit=-13 a0=bff31eff a1=1 a2=8050204 a3=bff30f40 items=1
pid=3865 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="rm" exe="/bin/rm"
type=PATH msg=audit(1135059155.826:81): item=0
name="/var/lock/subsys/sendmail" flags=10 inode=7602207 dev=fd:00
mode=040755 ouid=0 ogid=0 rdev=00:00
type=AVC msg=audit(1135059155.826:82): avc: denied { getattr } for
pid=3857 comm="K30sendmail" name="sm-client.pid" dev=dm-0 ino=7602308
scontext=system_u:system_r:sendmail_launch_t:s0
tcontext=root:object_r:var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1135059155.826:82): arch=40000003 syscall=195
success=no exit=-13 a0=8113cf8 a1=bfe448b8 a2=aedff4 a3=8110710 items=1
pid=3857 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="K30sendmail" exe="/bin/bash"
type=AVC_PATH msg=audit(1135059155.826:82): path="/var/run/sm-client.pid"
type=PATH msg=audit(1135059155.826:82): item=0
name="/var/run/sm-client.pid" flags=1 inode=7602308 dev=fd:00
mode=0100644 ouid=51 ogid=51 rdev=00:00
---
#ls -lZ
-rw------- root smmsp root:object_r:var_run_t sendmail.pid
-rw-r--r-- smmsp smmsp root:object_r:var_run_t sm-client.pid
-rw-r--r-- root root root:object_r:var_lock_t sendmail
Problem 2.
ping is called by bash script, executed by cron with root rights (comand
line: ping -c 1 -w 5 > /dev/null )
---
type=AVC msg=audit(1133295301.930:2739): avc: denied { write } for
pid=30341 comm="ping" name="[56893]" dev=pipefs ino=56893
scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0
tclass=fifo_file
type=AVC msg=audit(1133295301.930:2739): avc: denied { read } for
pid=30341 comm="ping" name="[56892]" dev=pipefs ino=56892
scontext=root:system_r:ping_t:s0 tcontext=system_u:system_r:crond_t:s0
tclass=fifo_file
---
Is any way to avoid such messages?
18 years, 4 months
samba share avcs
by Steve G
Hi,
This is a long standing problem that causes me to do "setenforce 0". I wished
there was a boolean to just turn of checking of samba or a streamlined way for
samba to relabel things on startup. In any event, I have a share, /src, which I
want to access across the network. It fails. This is what I see in the logs:
type=PATH msg=audit(12/23/2005 10:37:26.180:20524) : item=0
name=gtk+-2.8.9/gdk-pixbuf/pixops/pixops.c inode=1934832 dev=03:07 mode=dir,755
ouid=sgrubb ogid=sgrubb rdev=00:00 obj=user_u:object_r:user_home_t:s0
type=CWD msg=audit(12/23/2005 10:37:26.180:20524) : cwd=/src
type=SYSCALL msg=audit(12/23/2005 10:37:26.180:20524) : arch=x86_64 syscall=stat
success=no exit=-13(Permission denied) a0=7fffffe1c720 a1=7fffffe1b120
a2=7fffffe1b120 a3=7fffffe1aaec items=1 pid=23380 auid=root uid=nobody gid=root
euid=nobody suid=root fsuid=nobody egid=nobody sgid=nobody fsgid=nobody comm=smbd
exe=/usr/sbin/smbd subj=root:system_r:smbd_t:s0
type=AVC msg=audit(12/23/2005 10:37:26.180:20524) : avc: denied { search } for
pid=23380 comm=smbd name=gtk+-2.8.9 dev=hda7 ino=1934832
scontext=root:system_r:smbd_t:s0 tcontext=user_u:object_r:user_home_t:s0
tclass=dir
What is the correct solution for this?
-Steve
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
18 years, 4 months
Fwd: FW: Neophyte question re: httpd under SELinux
by Al Pacifico
> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Thursday, December 22, 2005 12:33 PM
> To: Al Pacifico
> Cc: fedora-selinux-list(a)redhat.com
> Subject: Re: Neophyte question re: httpd under
> SELinux
>
> Al Pacifico wrote:
> > Marcus-
> >
> > Thanks for your response.
> >
> > This helped some, I think, but I still have my
> issues.
> >
> > The URL
> >
>
http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizin
> > g.html#sn-httpd-booleans didn't contribute much.
> >
> > Output of ls -Z showed directories of my .../test
> directory as
> > user_u:object_r:user_home_t.
> >
> > Changing context with chcon -Rv -t
> httpd_sys_script_t ./test (as root) did
> > not work... lot of permission denied messages. My
> machine has a multidisk
> > setup and /home is its own partition or disk; not
> sure if that matters.
> >
> > Output of getsebool -a | grep httpd is:
> >
> > allow_httpd_anon_write --> inactive
> > allow_httpd_sys_script_anon_write --> inactive
> > httpd_builtin_scripting --> active
> > httpd_can_network_connect --> inactive
> > httpd_disable_trans --> active
> > httpd_enable_cgi --> active
> > httpd_enable_ftp_server --> inactive
> > httpd_enable_homedirs --> active
> > httpd_ssi_exec --> active
> > httpd_suexec_disable_trans --> inactive
> > httpd_tty_comm --> inactive
> > httpd_unified --> active
> >
> > I totally agree with the comment about placing
> files in the correct
> places,
> > on a production machine. However, numerous apache
> modules come with
> testing
> > suites that use the system httpd executable
> (appropriately) in other
> > locations.
> >
> > I'm starting to believe that I should either use
> setenforce 0 when
> > developing. If I do that, and forget to turn it
> back on, will there be
> some
> > ugly ramifications later? I have to halt httpd
> from the console using
> ctrl-C
> > because of the -X option, so I can't just stick
> setenforce 1 in my script.
> > (Hmm.... how do I trap ctrl-C in a bash script?) I
> could switch to testing
> > with lighttpd for CGI and SCGI, but I do need to
> test some apache modules
> > for which that is not an option.
> >
> > Two things I still don't unmderstand:
> > Why doesn't the "Disable SELinux protection for
> httpd daemon" checkbox
> just
> > take care of the problem?
> > My /var/log/messages didn't help me... doesn't
> show all those permission
> > denied messages when I tried to recusively change
> the context in my
> .../test
> > directory. Should I be looking elsewhere? Do I
> need to tell SELinux
> > something?
> >
> > I'm sorry if my questions are pretty basic; I
> definitely fall in the
> > category of 80% just want to get the job done and
> 20% want to know more.
> >
> > Thanks.
> > -al
> >
> > -----Original Message-----
> > From: fedora-selinux-list-bounces(a)redhat.com
> > [mailto:fedora-selinux-list-bounces@redhat.com] On
> Behalf Of Marcus O.
> White
> > Sent: Wednesday, December 21, 2005 2:20 AM
> > To: fedora-selinux-list(a)redhat.com
> > Subject: Re: Neophyte question re: httpd under
> SELinux
> >
> > On Tue, 2005-12-20 at 22:26 -0800, Al Pacifico
> wrote:
> >
> >> I'm working on a CGI program in C, but recently
> SELinux seems to have
> >> tripped me up.
> >>
> >> I started with Tom Boutell's cgic and an example
> CGI program (provided in
> >> his source tree) that generates a JPEG on the
> fly. It ran fine months
> back
> >> with the following script:
> >>
> >> dir=$(dirname $0)
> >> /usr/sbin/httpd -X -k start -d $dir -e debug
> >>
> >> on my FC4 machine.
> >>
> >> Now, it's time to start testing the program I
> wrote, but my Apache
> >>
> > (version
> >
> >> 2.0.54, installed from Fedora RPM, if it matters)
> won't start unless I
> >> execute /usr/sbin/setenforce 0 before executing
> my script. (it took me a
> >> while to figure that one out!). In fact,
> /usr/sbin/httpd -v won't even
> >>
> > work.
> >
> >> I'm sure the SELinux policy has updated via yum
> since times when it
> >>
> > worked,
> >
> >> and that explains the change. I tried checking
> "Disable SELinux
> protection
> >> for httpd daemon" in the
> system-config-securitylevel dialog and
> >>
> > relabelling
> >
> >> my filesystems, but I still need to execute
> /usr/sbin/setenforce 0
> >> beforehand to run my script that starts httpd
> with my CGI program.
> >>
> >> If it helps, the example CGI program (not the one
> I've written, but Tom
> >> Boutell's that formerly ran) is in the directory
> >>
> >>
>
/home/myuser/Development/myproject/imageFromCGI_test/test
>
> >>
> >> and
> >>
> >> ls -l
>
/home/myuser/Development/myproject/imageFromCGI_test/test
> outputs
> >>
> >> total 52
> >> drwxrwxr-x 2 myuser apache 4096 Sep 9 10:03
> cgi-bin
> >> drwxrwxr-x 2 myuser apache 4096 Sep 9 13:07
> conf
> >> -rwxr-xr-x 1 root root 63 Dec 20 14:38
> debug_CGI
> >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:08
> htdocs
> >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04
> logs
> >> lrwxrwxrwx 1 root root 18 Sep 9 09:52
> modules -> /etc/httpd/modules
> >> drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 run
> >>
> >> (probably only makes sense if you're accustomed
> to configuring apache;
> >>
> > this
> >
> >> directory is essentially the argument to the
> Apache ServerRoot
> directive).
> >>
> >> I inferred that the directory might be important
> since /sbin/service
> httpd
> >> start works fine, regardless of state of
> aforementioned checkbox.
> >>
> >> What bugs me is that I don't get any kind of
> warning... apache just never
> >> starts.
> >> Q: How do I get warnings? (grep avc
> /var/log/messages was of no help to
> my
> >> pea-brain)
> >> Q: What else do I need to change to alter this
> behavior?
> >>
> >> I understand that for a production machine,
> SELinux is a good thing. I
> >> hadn't installed it when I used FC2 and hadn't
> had much problem with FC3
> >>
> > or
> >
> >> with FC4 until yesterday. I have to believe there
> is a better way than
> >>
> > just
> >
> >> turning it off.
> >>
> >> Thanks.
> >> -al
> >>
> >> Al Pacifico
> >> Seattle, WA
> >>
> >>
> >>
> >>
> >> --
> >> fedora-selinux-list mailing list
> >> fedora-selinux-list(a)redhat.com
> >>
>
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>
> >
> > >From RHEL list:
> >
> > Gavin Young wrote:
> >
> >> Hey guys, hopefully someone out there can help me
> with this because
> >>
> > I'm
> >
> >> an SELinux virgin so to speak.
> >>
> >> We have a RHEL v4 box running apache amongst
> other things. No changes
> >> have been made to the standard Redhat policies.
> >>
> >
> > I'm no expert but I am trying to wade through
> Apache/selinux issues as
> > well.
> > You might find the following "beta" document
> helpful:
> >
> >
>
<http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizi
> > ng.html#sn-httpd-booleans>
> >
> > -------------------
> > On Fri, 4 Mar 2005, Gavin Young wrote:
> >
> >
> >> Hey guys, hopefully someone out there can help me
> with this because
> >>
> > I'm
> >
> >> an SELinux virgin so to speak.
> >>
> >> We have a RHEL v4 box running apache amongst
> other things. No changes
> >> have been made to the standard Redhat policies.
> >>
> >> We are wanting to run a perl based web app
> (Sql-Ledger)
> >> from /usr/local/sql-ledger but SELinux is
> stopping us.
> >>
> >> With SELinux disabled it works correctly. When
> SELinux protection of
> >>
> > the
> >
> >> HTTPD daemon is switched on the browser displays:
> Internal Server
> >>
> > Error
> >
> >> and /var/log/messages reports
> >>
> >> Mar 3 15:13:23 zorb1 kernel:
> audit(1109816003.103:0): avc: denied
> >> { execute } for pid=24711 exe=/usr/sbin/httpd
> name=login.pl dev=dm-0
> >> ino=9228595 scontext=root:system_r:httpd_t
> >>
> > tcontext=root:object_r:usr_t
> >
> >> tclass=file
> >>
> >>
> >>> From what I can tell SELinux is stopping scripts
> being run from any
> >>>
> >> other directory apart from /var/www/cgi-bin. I
> have tried moving the
> >> sql-ledger directory into cgi-bin but that
> doesn't appear to help
> >> because it is still a sub-directory of cgi-bin.
> >>
> >
> > The release notes give a hint to the right
> direction but doesn't
> > directly
> > talk about cgi - you need to set the file contexts
> of the sql-ledger
> > stuff
> > as cgi-content, something like this:
> > "chcon -R -h -t httpd_sys_script_exec_t <path to
> slq-ledger directory>"
> >
> > - Panu -
> >
> > ----------------------
> >
> > What are the HTTPD Booleans set to?
> >
> > getsebool -a | grep httpd
> >
> > httpd_enable_cgi needs to be active, if it is not.
> That wouldn't
> > generate the denial you have, so think of this as
> a "is it plugged in?"
> > type of question.
> >
> >
> >> We are wanting to run a perl based web app
> (Sql-Ledger)
> >> from /usr/local/sql-ledger but SELinux is
> stopping us.
> >>
> >
> > This is where someone could correct me for best
> practices advise.
> >
> > You want to seriously consider moving the CGI
> program to the appropriate
> > directory. Otherwise, you are trying to give
> Apache execute access to
> > something inside of /usr/local/ ...
> >
> > To do this in /usr/local/, you will need to change
> policy or
> > relabel /usr/local/ to make this happen, which
> will serve to reduce
> > security on the system.
> >
> >
> >> With SELinux disabled it works correctly. When
> SELinux protection of
> >>
> > the
> >
> >> HTTPD daemon is switched on the browser displays:
> Internal Server
> >>
> > Error
> >
> >> and /var/log/messages reports
> >>
> >> Mar 3 15:13:23 zorb1 kernel:
> audit(1109816003.103:0): avc: denied
> >> { execute } for pid=24711 exe=/usr/sbin/httpd
> name=login.pl dev=dm-0
> >> ino=9228595 scontext=root:system_r:httpd_t
> >>
> > tcontext=root:object_r:usr_t
> >
> >> tclass=file
> >>
> >> >From what I can tell SELinux is stopping scripts
> being run from any
> >> other directory apart from /var/www/cgi-bin. I
> have tried moving the
> >> sql-ledger directory into cgi-bin but that
> doesn't appear to help
> >> because it is still a sub-directory of cgi-bin.
> >>
> >
> > That shouldn't be a problem. You just need to
> relabel the directory
> > recursively. This should work, and is a good
> practice since it refers
> > to the mapping of labels to directories/files as
> defined by the policy:
> >
> > restorecon -Rv /var/www/cgi-bin/sql-ledger/
> >
> > If ls -Z doesn't show that the type is
> httpd_sys_script_t, do this:
> >
> > chcon -Rv -t httpd_sys_script_t
> /var/www/cgi-bin/sql-ledger/
> >
> >
> >> This problem must have come up before... Any help
> would be much
> >> appreciated.
> >>
> >
> > Yeah, almost qualifies for a FAQ.
> >
> > Future updates to the Red Hat SELinux Guide[1]
> will likely address
> > Apache more thoroughly.
> >
> > - Karsten
> > [1]
> >
>
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/in
> > dex.html
> >
> > HTH
> >
> > Marcus O.
> >
> >
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list(a)redhat.com
> >
>
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> >
> >
> >
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list(a)redhat.com
> >
>
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> What avc messages are you seeing. With
> httpd_enable_homedirs turned on
> apache should be able to read your homedirs.
> If you are seeing file_t in your
> /var/log/audit/audit.log then you
> probably need to relabel your system.
>
> touch /.autorelabel
> reboot
>
> --
>
>
>
>
>
Thanks, Daniel!
Still stumped. I've reduced this to a simple case that
can be executed on any FC4 box (updated via yum) that
has the httpd RPM and SELinux, so that you might be
able to look on your machine.
[root@powell imageFromCGI_test]# /usr/sbin/httpd -V
<expected to see server version, etc, but no
response>
[root@powell imageFromCGI_test]# /usr/sbin/setenforce
0
<try again with SELinux off>
[root@powell imageFromCGI_test]# /usr/sbin/httpd -V
Server version: Apache/2.0.54
Server built: Sep 2 2005 11:54:18
<snip>
[root@powell imageFromCGI_test]# /usr/sbin/setenforce
1
<SELinux back on>
[root@powell imageFromCGI_test]# /usr/sbin/httpd -V
[root@powell imageFromCGI_test]#
Output of grep AVC /var/log/audit/audit.log now ends
with:
type=AVC msg=audit(1135317046.340:535): avc: granted
{ setenforce } for pid=8452 comm="setenforce"
scontext=root:system_r:unconfined_t
tcontext=system_u:object_r:security_t tclass=security
type=AVC msg=audit(1135317060.595:536): avc: granted
{ setenforce } for pid=8454 comm="setenforce"
scontext=root:system_r:unconfined_t
tcontext=system_u:object_r:security_t tclass=security
Shouldn't there have been a message following the last
line saying my execution of /usr/sbin/httpd -V was
denied?
Output of getsebool -a | grep httpd is still:
allow_httpd_anon_write --> inactive
allow_httpd_sys_script_anon_write --> inactive
httpd_builtin_scripting --> active
httpd_can_network_connect --> inactive
httpd_disable_trans --> active
httpd_enable_cgi --> active
httpd_enable_ftp_server --> inactive
httpd_enable_homedirs --> active
httpd_ssi_exec --> active
httpd_suexec_disable_trans --> inactive
httpd_tty_comm --> inactive
httpd_unified --> active
Any ideas? Clearly, I'm missing something, here.
-al
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
18 years, 4 months
Neophyte question re: httpd under SELinux
by Al Pacifico
I'm working on a CGI program in C, but recently SELinux seems to have
tripped me up.
I started with Tom Boutell's cgic and an example CGI program (provided in
his source tree) that generates a JPEG on the fly. It ran fine months back
with the following script:
dir=$(dirname $0)
/usr/sbin/httpd -X -k start -d $dir -e debug
on my FC4 machine.
Now, it's time to start testing the program I wrote, but my Apache (version
2.0.54, installed from Fedora RPM, if it matters) won't start unless I
execute /usr/sbin/setenforce 0 before executing my script. (it took me a
while to figure that one out!). In fact, /usr/sbin/httpd -v won't even work.
I'm sure the SELinux policy has updated via yum since times when it worked,
and that explains the change. I tried checking "Disable SELinux protection
for httpd daemon" in the system-config-securitylevel dialog and relabelling
my filesystems, but I still need to execute /usr/sbin/setenforce 0
beforehand to run my script that starts httpd with my CGI program.
If it helps, the example CGI program (not the one I've written, but Tom
Boutell's that formerly ran) is in the directory
/home/myuser/Development/myproject/imageFromCGI_test/test
and
ls -l /home/myuser/Development/myproject/imageFromCGI_test/test outputs
total 52
drwxrwxr-x 2 myuser apache 4096 Sep 9 10:03 cgi-bin
drwxrwxr-x 2 myuser apache 4096 Sep 9 13:07 conf
-rwxr-xr-x 1 root root 63 Dec 20 14:38 debug_CGI
drwxrwxr-x 2 myuser apache 4096 Sep 9 12:08 htdocs
drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 logs
lrwxrwxrwx 1 root root 18 Sep 9 09:52 modules -> /etc/httpd/modules
drwxrwxr-x 2 myuser apache 4096 Sep 9 12:04 run
(probably only makes sense if you're accustomed to configuring apache; this
directory is essentially the argument to the Apache ServerRoot directive).
I inferred that the directory might be important since /sbin/service httpd
start works fine, regardless of state of aforementioned checkbox.
What bugs me is that I don't get any kind of warning... apache just never
starts.
Q: How do I get warnings? (grep avc /var/log/messages was of no help to my
pea-brain)
Q: What else do I need to change to alter this behavior?
I understand that for a production machine, SELinux is a good thing. I
hadn't installed it when I used FC2 and hadn't had much problem with FC3 or
with FC4 until yesterday. I have to believe there is a better way than just
turning it off.
Thanks.
-al
Al Pacifico
Seattle, WA
18 years, 4 months
java failure
by Tom London
Running targeted/enforcing, latest rawhide(selinux-policy-targeted-2.1.6-11):
executing 'java' produces "error spawning gij"
audit.log shows:
type=SELINUX_ERR msg=audit(1135117790.324:65): security_compute_sid:
invalid context user_u:system_r:java_t:s0 for
scontext=user_u:system_r:unconfined_t:s0
tcontext=system_u:object_r:java_exec_t:s0 tclass=process
type=SYSCALL msg=audit(1135117790.324:65): arch=40000003 syscall=11
success=no exit=-13 a0=804877a a1=bff00d94 a2=9149040 a3=320cc0
items=1 pid=6726 auid=4294967295 uid=500 gid=500 euid=500 suid=500
fsuid=500 egid=500 sgid=500 fsgid=500 comm="java"
exe="/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre/bin/java"
type=CWD msg=audit(1135117790.324:65): cwd="/home/tbl/Downloads/azureus"
type=PATH msg=audit(1135117790.324:65): item=0 name="/usr/bin/gij"
flags=101 inode=137573 dev=fd:00 mode=0100755 ouid=0 ogid=0
rdev=00:00
This known?
tom
--
Tom London
18 years, 4 months
RE: Problem with VNC and SELinux: FC4
by chanson＠TrustedCS.com
>Folks,
>
>With the new SELinux updates, it appears that root,
>other than normal users can login to Fedora via VNC
>Server? My VNC Server is setup such that I am using
>xinitd for VNC Server requests.
>
A problem I noticed on FC4 with updates is that running VNC from initscripts
will cause user sessions to have a system_u:system_r:initrc_t context. If
you start a VNC server as the user from a shell, you get get the expected
behavior of unconfined_t session.
>Another problem I noticed is that when I log into my
>Fedora system via VNC as root user, and open a xterm
>window and run a su - <normal-user>, I get back a
>SElinux message:
>
>================================================
># su - dan
>Your default context is: user_u:system_r:kernel_t.
>
>Do you want to want to choose a different one? [n]
>================================================
18 years, 4 months
rawhide policy error messages
by Steve G
Hi,
I updated selinux targeted policy in rawhide and got this:
Running Transaction
Installing: selinux-policy ######################### [1/3]
Updating : selinux-policy-targeted ######################### [2/3]
security: invalidating context system_u:object_r:hostname_exec_t:s0
security: invalidating context system_u:system_r:hostname_t:s0
libsemanage.parse_module_headers: Data did not represent a module.
Failed!
/sbin/restorecon reset /bin/hostname context
system_u:object_r:unlabeled_t->system_u:object_r:bin_t
/sbin/restorecon reset /usr/lib/dri/radeon_dri.so context
system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t
Cleanup : selinux-policy-targeted ######################### [3/3]
Anything to worry about? Does the message from libsemanage actually give enough
information to fix the problem?
-Steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
18 years, 4 months
RE: Non-root console login issue! (was: Problem with VNC ... SELinux:FC4)
by Dan Thurman
>From: fedora-list-bounces(a)redhat.com
>[mailto:fedora-list-bounces@redhat.com]On Behalf Of Daniel J Walsh
>Sent: Tuesday, December 20, 2005 11:20 AM
>To: For users of Fedora Core releases
>Cc: Fedora SELinux support list for users & developers.
>Subject: Re: Non-root console login issue! (was: Problem with VNCand
>SELinux:FC4)
>
>
>Daniel B. Thurman wrote:
>>> From: fedora-list-bounces(a)redhat.com
>>> [mailto:fedora-list-bounces@redhat.com]On Behalf Of Daniel
>B. Thurman
>>> Sent: Saturday, December 17, 2005 2:30 PM
>>> To: For users of Fedora Core releases
>>> Cc: Fedora SELinux support list for users & developers.
>>> Subject: Non-root console login issue! (was: Problem with VNC and
>>> SELinux:FC4)
>>>
>>>
>>>
>>>> From: fedora-list-bounces(a)redhat.com
>>>> [mailto:fedora-list-bounces@redhat.com]On Behalf Of Daniel
>B. Thurman
>>>> Sent: Friday, December 16, 2005 6:11 PM
>>>> To: For users of Fedora Core releases (E-mail)
>>>> Cc: Fedora SELinux support list for users & developers.
>>>> Subject: Problem with VNC and SELinux: FC4
>>>>
>>>>
>>>>
>>>> Folks,
>>>>
>>>> With the new SELinux updates, it appears that root,
>>>> other than normal users can login to Fedora via VNC
>>>> Server? My VNC Server is setup such that I am using
>>>> xinitd for VNC Server requests.
>>>>
>>>> Another problem I noticed is that when I log into my
>>>> Fedora system via VNC as root user, and open a xterm
>>>> window and run a su - <normal-user>, I get back a
>>>> SElinux message:
>>>>
>>>> ================================================
>>>> # su - dan
>>>> Your default context is: user_u:system_r:kernel_t.
>>>>
>>>> Do you want to want to choose a different one? [n]
>>>> ================================================
>>>>
>>>> It is *possible* that this problem came up when
>>>> I had to make a copy of my filesystem to another
>>>> hard-disk for the purpose of creating a /boot
>>>> partition (my bad) and copied/restored the filesystem
>>>> back over to the main drive. I don't think I made
>>>> any copy/restore mistakes as I know the fs permissions
>>>> are correct but I cannot speak for filesystem journaling
>>>> or whatever that keeps track of the SELinux attributes.
>>>>
>>>> In any case, what can I do to resolve my VNC and/or su
>>>> issue knowing that SElinux has something to do with it?
>>>>
>>>> Thanks!
>>>> Dan Thurman
>>>>
>>>>
>>> Problem is not related to SELinux and not really related
>>> to VNC. It turns out that I cannot log into the console
>>> as a non-root user and I get a message saying:
>>>
>>> =======================================================
>>> Your session lasted less than 10 seconds. If you have not
>>> logged out yourself, this could mean that there is some
>>> installation problem or that you may be out of diskspace.
>>> Try logging in with one of the failsafe sessions to see if
>>> you can fix this problem.
>>>
>>> [] View details (~/.xsession-errors file)
>>> =======================================================
>>>
>>> The problem here is that the .xsession-errors file does
>>> not exist. I also note from /var/log/message file:
>>>
>>> =======================================================
>>> Dec 17 12:45:31 linux gdm(pam_unix)[16480]: session opened for
>>> user dant by (uid=0)
>>> Dec 17 12:45:32 linux gdm(pam_unix)[16480]: session closed for
>>> user dant
>>> Dec 17 12:45:32 linux dbus: avc: 0 AV entries and 0/512
>>> buckets used, longest chain length 0
>>> =======================================================
>>>
>>> And from /var/log/audit/audit.log
>>> =======================================================
>>> type=USER_AUTH msg=audit(1134858412.155:3929): user pid=3397
>>> uid=0 auid=4294967295 msg='PAM authentication: user=dant
>>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0
>>> result=Success)'
>>> type=USER_ACCT msg=audit(1134858412.159:3930): user pid=3397
>>> uid=0 auid=4294967295 msg='PAM accounting: user=dant
>>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0
>>> result=Success)'
>>> type=CRED_ACQ msg=audit(1134858412.247:3931): user pid=3397
>>> uid=0 auid=4294967295 msg='PAM setcred: user=dant
>>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0
>>> result=Success)'
>>> type=USER_START msg=audit(1134858412.307:3932): user pid=3397
>>> uid=0 auid=4294967295 msg='PAM session open: user=dant
>>> exe="/usr/bin/gdm-binary" (hostname=?, addr=?, terminal=:0
>>> result=Success)'
>>> =======================================================
>>>
>>> File:
>>> # ls -l /usr/bin/gdm-binary
>>> -rwxr-xr-x 1 root root 251668 May 23 2005 /usr/bin/gdm-binary
>>>
>>> HALLLLLP! Please :-)
>>>
>>> Dan
>>>
>>>
>>
>> Sorry - had to add this tidbit.... seems that SElinux may be
>> involved or maybe my file journaling is messed up after a "restore"?
>>
>> I tried to create a new user account to see if by doing this
>> I would get a correct security context and be able to log
>> into the console but WHOA!!! What is going on here!?!?!?
>>
>> =======================================================
>> [root@linux ~]# useradd dant2
>> useradd: cannot rewrite password file
>> [root@linux ~]#
>> =======================================================
>> File: /var/log/audit/audit.log:
>>
>> 94967295 msg='useradd: op=adding home directory acct=dant2
>res=success'
>> type=AVC msg=audit(1134859204.879:4004): avc: denied {
>create } for pid=19177 comm="useradd" name=".kde"
>scontext=root:system_r:kernel_t
>tcontext=user_u:object_r:user_home_t tclass=dir
>> type=SYSCALL msg=audit(1134859204.879:4004): arch=40000003
>syscall=39 success=no exit=-13 a0=bfd81470 a1=1ed a2=98fd2ef
>a3=ffffffff items=1 pid=19177 auid=4294967295 uid=0 gid=0
>euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd"
>exe="/usr/sbin/useradd"
>> type=CWD msg=audit(1134859204.879:4004): cwd="/root"
>> type=PATH msg=audit(1134859204.879:4004): item=0
>name="/home/dant2/.kde" flags=10 inode=1245989 dev=03:02
>mode=040755 ouid=511 ogid=512 rdev=00:00
>> type=AVC msg=audit(1134859204.883:4005): avc: denied {
>create } for pid=19177 comm="useradd" name="passwd+"
>scontext=root:system_r:kernel_t
>tcontext=system_u:object_r:file_t tclass=file
>> type=SYSCALL msg=audit(1134859204.883:4005): arch=40000003
>syscall=5 success=no exit=-13 a0=bfd817e4 a1=8241 a2=1b6
>a3=98f6f38 items=1 pid=19177 auid=4294967295 uid=0 gid=0
>euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="useradd"
>exe="/usr/sbin/useradd"
>> type=CWD msg=audit(1134859204.883:4005): cwd="/root"
>> type=PATH msg=audit(1134859204.883:4005): item=0
>name="/etc/passwd+" flags=310 inode=1212417 dev=03:02
>mode=040755 ouid=0 ogid=0 rdev=00:00
>> type=USER_CHAUTHTOK msg=audit(1134859204.883:4006): user
>pid=19177 uid=0 auid=4294967295 msg='useradd: op=adding user
>acct=dant2 res=failed'
>> =======================================================
>>
>> Dan
>>
>>
>Looks like you have a labeling problem. file_t files should not exist
>if your system is properly labeled. This either indicates you booted
>with selinux=0 or you added additional disks.
>
>You can relabel by executing
>
>touch /.autorelabel
>reboot
From: RE: [mostly solved] SELinux is screwing me up!!!! Help!
Date: Mon 12/19/2005 8:21AM
I did try the autorelabel as it did not work. It wasn't
until I tried the following that seemed to steer clear of
permissions problems encountered with the autorelabel method.
==========================================
I think that I solved this problem by:
1) Booting in selinux=0 single
2) /sbin/fixfiles -F -R -a -F relabel
3) reboot
==========================================
Sorry that you did not see this later thread.
Dan
>
>
>--
>
>
>--
>fedora-list mailing list
>fedora-list(a)redhat.com
>To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.371 / Virus Database: 267.14.1/207 - Release
>Date: 12/19/2005
>
>
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.1/207 - Release Date: 12/19/2005
18 years, 4 months
