On 05/26/2010 08:23 PM, Gordon Messmer wrote:
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
[...]
The *theoretical* system security improvement of SELinux is trumped by
the *practical* observation that I have had existing systems broken by
SELinux multiple times on the mere handful of
On Thu, 2010-05-27 at 05:55 -0700, Jerry Franz wrote:
On 05/26/2010 08:23 PM, Gordon Messmer wrote:
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
[...]
The *theoretical* system security improvement of SELinux is trumped by
the *practical* observation that I have had existing systems
On 05/27/2010 05:55 AM, Jerry Franz wrote:
I have *twenty* virtual machines I deploy updates to before it ever
touches my production systems. Not everything is testable on
non-production machines.
...
Now back to fixing the SELinux configuration on a machine I had to put
in 'permissive' mode
On 05/27/2010 08:51 AM, Gordon Messmer wrote:
On 05/27/2010 05:55 AM, Jerry Franz wrote:
I have *twenty* virtual machines I deploy updates to before it ever
touches my production systems. Not everything is testable on
non-production machines.
...
Now back to fixing the
On May 26, 2010, at 1:44 AM, Les Mikesell lesmikes...@gmail.com wrote:
Gordon Messmer wrote:
No. With that file removed, smbd probably wouldn't have been able to
write to the directory. If it was able to, it probably would have
run
into trouble with the next file. If smbd started up in
On Tue, 2010-05-25 at 21:27 -0400, Whit Blauvelt wrote:
But if someone can tell me why selinux thinks it's sane to block
/etc/init.d/smb start while leaving sh /etc/init.d/smb start and even
/some/random/dir/smb start wide open ... I just can't believe some happy
hacker at NSA thought that
JohnS wrote:
On Tue, 2010-05-25 at 21:27 -0400, Whit Blauvelt wrote:
But if someone can tell me why selinux thinks it's sane to block
/etc/init.d/smb start while leaving sh /etc/init.d/smb start and even
/some/random/dir/smb start wide open ... I just can't believe some happy
hacker at NSA
On Tue, 2010-05-25 at 23:36 -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 09:09:33PM -0500, Jay Leafey wrote:
In your case, there should have been AVC errors showing up in the
audit log related to smbd. Using restorecon to fix up the security
context on the files in /etc/samba
you can't make a useful argument out of ignorance.
You are being religious, and wrong. See below.
If you don't want to use SELinux, then disable it.
This is a good idea. Disabling SELinux is the first thing that should
be done, since (as this conversation proves plainly) what we don't
On 05/26/2010 07:40 AM, Craig White wrote:
you can't make a useful argument out of ignorance. If you don't want to
use SELinux, then disable it. Otherwise, learn to understand how it
operates and deal with it.
one certain way to cause issues with SELinux is to copy files created in
other
Benjamin wrote:
On 05/26/2010 07:40 AM, Craig White wrote:
you can't make a useful argument out of ignorance. If you don't want to
use SELinux, then disable it. Otherwise, learn to understand how it
operates and deal with it.
one certain way to cause issues with SELinux is to copy files
The *theoretical* system security improvement of SELinux is trumped by
the *practical* observation that I have had existing systems broken by
SELinux multiple times on the mere handful of systems I have run it on
in enforcing mode, but have yet to see a single one of several dozen
(all
On 05/25/2010 10:44 PM, Les Mikesell wrote:
That still doesn't explain why there is a difference in smbd's context when
its
parent is an explicitly started shell vs. the implict one that starts when the
script file is executed.
SELinux domain transitions are handled by the kernel. If you
On 05/26/2010 07:54 AM, Brunner, Brian T. wrote:
you can't make a useful argument out of ignorance.
You are being religious, and wrong. See below.
You also can't make a useful argument out of name-calling.
People frequently use the label religious derisively when someone
advocates a
On 5/26/2010 5:16 PM, Gordon Messmer wrote:
Isn't the context associated with the program itself,
not its parent?
The context is inherited from the process which calls exec() if there is
no transition defined. If there is a transition, it is associated with
the path.
Is this documented
On 05/26/2010 08:44 AM, Benjamin Franz wrote:
I can make a useful argument from experience. Over the last few years,
as Redhat has progressively deployed SELinux, I have had *several*
incidents (the most recent only a few weeks ago) where updates to
SELinux broke existing, stable, systems.
On Tue, May 25, 2010 at 07:55:12PM -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
You were right Jerry!
echo 0 /selinux/enforce
and then /etc/init.d/smb restart works! Thank you much Jerry!
Now why doesn't that
Whit Blauvelt wrote:
On Tue, May 25, 2010 at 07:55:12PM -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
You were right Jerry!
echo 0 /selinux/enforce
and then /etc/init.d/smb restart works! Thank you much
On May 25, 2010, at 8:25 PM, Whit Blauvelt w...@transpect.com wrote:
On Tue, May 25, 2010 at 07:55:12PM -0400, Whit Blauvelt wrote:
On Tue, May 25, 2010 at 04:33:53PM -0700, Jerry Franz wrote:
Are you running with SELinux on?
You were right Jerry!
echo 0 /selinux/enforce
and then
On Tue, May 25, 2010 at 07:46:56PM -0500, Les Mikesell wrote:
I would have looked at selinux first for any odd failure, but I thought it
related to the process itself and couldn't see any way that the process would
be
different when started as sh /etc/init.d/smb restart than simply
On Tue, May 25, 2010 at 08:52:58PM -0400, Ross Walker wrote:
Selinux alerts are in /var/log/audit/audit.log
Thank you for that. Cryptic, but there it is.
The problem is if smbd doesn't create the messages.tdb file then it
won't have the selinux rights.
I don't follow you. What else could
-Original Message-
From: centos-boun...@centos.org
[mailto:centos-boun...@centos.org] On Behalf Of Whit Blauvelt
Sent: Tuesday, May 25, 2010 21:27
To: CentOS mailing list
Subject: Re: [CentOS] Odd failure of smbd to start from
init.d - CentOS 5.4 - it's that fine SELinux
Whit Blauvelt wrote:
SNIP
Then why was it also happy with sh /etc/init.d/smb start but not
/etc/init.d/smb start. I'm happy to become more educated on this. But if
invoking a major daemon startup that selinux wants to block is as easy as
that, selinux is window dressing, not security.
What am
On May 25, 2010, at 9:44 PM, Whit Blauvelt w...@transpect.com wrote:
On Tue, May 25, 2010 at 08:52:58PM -0400, Ross Walker wrote:
Selinux alerts are in /var/log/audit/audit.log
Thank you for that. Cryptic, but there it is.
The problem is if smbd doesn't create the messages.tdb file then it
On Tue, May 25, 2010 at 10:03:38PM -0400, Jason Pyeron wrote:
If you look at it as the two different commands, then they may have different
permissions, owners, contexts, etc...
/bin/sh vs /etc/init.d/smb
I am just logically guessing here but ...
Let me follow your logic here. So the
Whit Blauvelt wrote, On 05/25/2010 11:09 PM:
On Tue, May 25, 2010 at 10:03:38PM -0400, Jason Pyeron wrote:
If you look at it as the two different commands, then they may have different
permissions, owners, contexts, etc...
/bin/sh vs /etc/init.d/smb
I am just logically guessing here but
On Tue, May 25, 2010 at 09:09:33PM -0500, Jay Leafey wrote:
In your case, there should have been AVC errors showing up in the
audit log related to smbd. Using restorecon to fix up the security
context on the files in /etc/samba might have resolved the issue
quickly... but I guess the trick
On 05/25/2010 06:44 PM, Whit Blauvelt wrote:
And that still doesn't say why it starts having a problem with
/var/cache/samba/messages.tbd. Does it?
That's simply the first file which was denied by policy. If that one
had been removed, the next one would have caused problems.
That file can
On 05/25/2010 08:36 PM, Whit Blauvelt wrote:
Thoughtful advice. Thanks. Is there some method to duplicate basic
configuration files across selinux servers without running restorecon for
each set of files that's copied over - that is, to copy them with their
selinux labels intact?
Usually if
On 05/25/2010 08:09 PM, Whit Blauvelt wrote:
So with selinux, in general any script that selinux would stop from running
due to the script's own extra selinux file tags can be run if Evil Intruder
simply invokes the same script with its shell first - sh or perl or python
or whatever? That
Gordon Messmer wrote:
No. With that file removed, smbd probably wouldn't have been able to
write to the directory. If it was able to, it probably would have run
into trouble with the next file. If smbd started up in the context
which was configured for it, everything would work
31 matches
Mail list logo
