FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-22-2008, 06:46 PM
"James B. Byrne"
 
Default

In-Reply-To: <f4e013870805211022r36194b29gb74ca4421dc2ee77@mail .gmail.com>

On: Wed, 21 May 2008 10:22:19 -0700, MHR <mhullrich@gmail.com>
wrote:

>> On Wed, May 21, 2008 at 8:37 AM, James B. Byrne <byrnejb@harte-lyne.ca>
>> wrote:
>>
>> This indeed turned out to be an SELinux policy problem which I have since
>> resolved.
>
> Whoa, whoa, whoa, nice shooting, Tex! (Ghostbusters)
>
> Not so fast - please post the solution, too, for posterity (and those
> of us who don't use SELinux but might, someday, in the not too distant
> far future...).
>
> Thanks.
>
> mhr

Dealings with SELinux issues typically do not lend themselves to short
answers. SELinux is like an onion, each each exception blocks access until
resolved. Thus each policy change has to be made individually and then the
process retested so that the next impediment evidences itself.

On CentOS-5 your friends are:

# grep avc /var/log/messages
# grep <process> /var/log/audit/audit.log

and some of the more useful utilities are:

# audit2allow
# audit2why
# chcon
# restorecon
# sealert
# semanage

When I suspect (and that is often the hardest part of the whole exercise,
realizing that SELinux is the problem) that SELinux is involved in a problem I
start by checking the system log file /var/log/messages with grep avc. If I
see things like this:

# grep avc /var/log/messages

May 16 04:02:33 inet01 kernel: audit(1210924952.785:22973): avc: denied {
read } for pid=22282 comm="prelink" name="setserial" dev=dm-0 ino=3309644
scontext=user_u:system_rrelink_t:s0
tcontext=system_ubject_r:rsync_data_t:s0 tclass=file

Then I infer that I have a problem with either the SELinux file contexts or
the system policy file. If the SELinux problem is announced at the desktop
then you may also find it useful to check for this:

# grep setroubleshoot /var/log/messages

In which case you may see something like this:

Dec 17 14:13:24 inet01 setroubleshoot:
SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d (etc_t).
For complete SELinux messages. run sealert -l
15618e2e-044c-4c4c-b3fc-ec1eba554d02

In this case you can follow the suggestion given in the log message and run
sealert:

# sealert -l 15618e2e-044c-4c4c-b3fc-ec1eba554d02
Summary
SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d
(etc_t).

Detailed Description
SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d
(etc_t). The SELinux type %TARGET_TYPE, is a generic type for all files in
the directory and very few processes (SELinux Domains) are allowed to write
... yada-yada-yada...
...
Allowing Access
You can attempt to fix file context by executing restorecon -v virtual.d

The following command will allow this access:
restorecon virtual.d

And then you can try that, although I have rarely had a problem with SELinux
solved so simply:

# cd /path/to/virtual.d
# restorecon virtual.d

Anyway, if that does not work, or one never received an setroubleshoot report
to begin with, then I end up turning to audit2allow. I do something like this
(where rsync is the process that I am having difficulty with, it could be
httpd, vsftp or anything else):

# grep rsync /var/log/audit/audit.log | audit2allow

Which may yield a report something like this:

#============= prelink_t ==============
allow prelink_t rsync_data_t:file read;

Now, if this does not look too alarming in terms of the access that rsync
seems to be seeking (being able to read files to be transferred seems a
logical enough expectation and the benefit/limitations of prelink seem to
require access in this instance) then we can add this permission to our policy
via a local module. You make one of these in this fashion:

#
# grep rsync /var/log/audit/audit.log | audit2allow -M localrsyncmod

******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i localrsyncmod.pp
#

Again, you simply follow the instructions given in the report.

# semodule -i localrsyncmod.pp

Now you do yet another test and check the log files. If the problem is fixed,
then great, you are finished. Usually, however, SELinux issues continually
reveal one permission problem after another, sometimes with different
processes, until, at last, they have all been accommodated. Consequently you
end up re-running your tests, checking the audit files, and modifying the
local policy one item at a time.

Note that simply overriding what SELinux is prohibiting is not what I am
advocating here. Sometimes the problem is that the software needs its file
system access expectations trimmed back and that requires filing a bug report
with the maintainers. However, in a production environment you normally just
have to get things working and what I usually do is weigh what the program is
requesting against what I want it to do for me. Often the problem is that the
default policy is simply too restrictive. On rare occasions I do actually
file a bug report but almost always override the local policy anyway just to
get on with the job.

I hope this helps.

--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-22-2008, 06:46 PM
Derek Broughton
 
Default

charlie derr wrote:

> Derek Broughton wrote:
>> Florian Diesch wrote:
>>
>>> I just don't know *any* GUI config tools that supports this things.
>>> And that's just the basics, with text file based configs you easily
>>> get versioning, template or rule based generation, automatic
>>> distribution, ...
>>
>> Nobody, at any point in this thread, has argued against "text file based
>> configs". I've argued against editing them with a text editor
>
> To be a bit more pedantic, I'd say that I have the impression you're
> arguing for (someday) not allowing others to be able to edit
> config files with a text editor. Until there are truly bulletproof
> well-tested solutions in existence (and not just vaporware in
> our dreams), I think most of us would disagree with that goal.

Hell, _I_ disagree with that! Of course, the config tool has to be there
first.

> I also think that in some respects, calling this a "GUI" issue is somewhat
> misleading.

I agree. I've said it was a bad choice of wording in my first post, though
I do think the tools would have to be graphical to meet most users
requirements.

> Having this checking built into the interface (so that it's impossible to
> even craft a config file with an invalid entry) doesn't really seem more
> valuable to me than a utility which
> could be run against a config file and alert on invalid entries, syntax
> errors, etc...

It's more valuable in that people routinely _don't_ use such tools - as
witnessed by the fact that at least two people on this thread appear to
have been maintaining Apache servers without knowing they could do that.

>> - and you
>> don't get _any_ of those benefits using vi.
>
> Well maybe that's true, but with emacs, I get all kinds of benefits :-]

But not out of the box - you still have to write the automation.
--
derek


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 07:06 PM
"Steve Lamb"
 
Default

On Thu, May 22, 2008 11:42 am, Derek Broughton wrote:
> Avi Greenbury wrote:
>> It depends on your interpretation of 'stupid' and 'never', I suppose.
>> What kind of domain that could never be registered, and that no-one
>> will ever want in their configuration, do you have in mind?

> Anything that's syntactically incorrect.

Yes, and Avi asked what that would be.

> And I'm being accused of not living in the real world. The world is full of
> pointy-haired bosses who couldn't care less that they've put the least
> technically competent person in charge of their web server...

At what point did that become our problem to solve and solve by hobbling
the competent people?

--
Steve Lamb


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 08:05 PM
Les Mikesell
 
Default

Florian Diesch wrote:
>
>> Nobody, at any point in this thread, has argued against "text file based
>> configs". I've argued against editing them with a text editor
>
> So it's fine to edit them as long as I don't use an editor?
>
>
>> - and you don't get _any_ of those benefits using vi.
>
> The nice thing about text files is that there are so many tools to
> work with them. Shouldn't be much of a problem to integrate them in a
> modern vi clone like vim.

Text editors like vi that know how to pipe and filter actually include
the functionality of any other program you can run that works with
stdin/stdout. For example, if you happen to be editing a config file
that is really a snippet of perl in vi and you'd like to know if it is
syntactically correct, you always have a perl syntax-checker at your
disposal. Just ":w !perl -c". And no extra bloat in the editor to
support that. Of course, checking functional correctness of perl code
takes a little more work.

--
Les Mikesell
lesmikesell@gmail.com


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 08:11 PM
Mario Vukelic
 
Default

On Thu, 2008-05-22 at 09:01 -0500, Cybe R. Wizard wrote:
<snipped Libranet>

I see, thanks for the info. I talked one Linux beginner into Libranet
once, which promptly died. That's why I was kind of interested in what
happened.

> BTW, thanks for the help you've given me on several occasions. Several
> times you've opened my eyes, even when I haven't been participating in
> the discussion.

I really (really!) did not write this part to solicit public gratitude
now, but, well, thanks It _is nice to know that someone had some
benefit, what else is there to ask for

> As for OT, I don't mind it, am mostly interested in the discussions and
> think they do more good than harm.

I do think that restraint is in order to keep the list a useful place, I
just think that sometimes it goes a little far.


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 08:18 PM
"Steve Lamb"
 
Default

On Thu, May 22, 2008 1:05 pm, Les Mikesell wrote:
> Of course, checking functional correctness of perl code
> takes a little more work.

Some ex-perl hackers would say that checking the functional correctness
of perl is also a pie-in-the-sky goal.

--
Steve Lamb


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 08:32 PM
Karl Larsen
 
Default

Derek Broughton wrote:
> Avi Greenbury wrote:
>
>
>>> Do you actually intentionally make "stupid" mistakes that can never
>>> possibly
>>> work? That's what a config tool should prevent. When a config value
>>> needs to be a domain name, it may be desirable to permit domains that
>>> can't currently be resolved, but it's never going to desirable to allow
>>> you to enter a domain that could never be registered.
>>>
>> It depends on your interpretation of 'stupid' and 'never', I suppose.
>> What kind of domain that could never be registered, and that no-one
>> will ever want in their configuration, do you have in mind?
>>
>
> Anything that's syntactically incorrect.
>
>
>> If you have, as you say, an idiot who can not and will not learn, and
>> they should be prevented from screwing up the servers, the easiest way
>> to accomplish that is to not let them anywhere near them, and let
>> someone who has learnt do the configuration.
>>
>
> And I'm being accused of not living in the real world. The world is full of
> pointy-haired bosses who couldn't care less that they've put the least
> technically competent person in charge of their web server...
>
I WAS the boss, and I was accused many times of putting the wrong
guy in the wrong place. When your the boss, you listen with care, and
then be quiet. Learn from what you were told. If the guy DOES have a
problem with the job, ask him what he would rather be doing. If he likes
his job, explain the problems you see. If he would rather be doing
another job you need then put him there in a two week moving window.
Tell the new Division Chief about his new man and the history.

I learned that the color of the skin has nothing to do with
performance. I learned a PHd can be lazy and poor at the job he took. I
had people who were way smarter than I am and better workers. I had a
girl who just got out of High School with a C- grade average. Hired her
to shuffle papers and found I liked her. Put her in the Development Lab
and she drove the boss there mad asking questions. As she learned she
smiled more and got to where she was getting assignments that she could
do very well. She was promoted to Senior Tech with a big raise. I asked
if she would attend Los Angeles City College and I paid the cost. She
got straight A grades for 2 years. On to UCLA and a BSEE and then MSEE
and then Stanford and PHd. She worked for me the entire time I was in
business. Got a huge amount of money back.

Karl


--

Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
PGP 4208 4D6E 595F 22B9 FF1C ECB6 4A3C 2C54 FE23 53A7


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-23-2008, 09:42 AM
Avi Greenbury
 
Default

On Thu, 22 May 2008 15:42:49 -0300
Derek Broughton <news@pointerstop.ca> wrote:
> And I'm being accused of not living in the real world. The world is full of
> pointy-haired bosses who couldn't care less that they've put the least
> technically competent person in charge of their web server...

But all your app will protect against is the incompetent from making
syntactical errors. If they're really incompetent, they're as likely to
make syntactically-legal configuration errors as they are spelling
mistakes.

I can't see how protecting from the former but not the latter helps
anyone, except, possibly, the jobless technically incompetent.

--
Avi Greenbury

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-23-2008, 03:12 PM
Fajar Priyanto
 
Default

On Friday 23 May 2008 01:46:33 James B. Byrne wrote:
> Dealings with SELinux issues typically do not lend themselves to short
> answers. SELinux is like an onion, each each exception blocks access until
> resolved. Thus each policy change has to be made individually and then the
> process retested so that the next impediment evidences itself.

> Note that simply overriding what SELinux is prohibiting is not what I am
> advocating here. Sometimes the problem is that the software needs its file
> system access expectations trimmed back and that requires filing a bug
> report with the maintainers. However, in a production environment you
> normally just have to get things working and what I usually do is weigh
> what the program is requesting against what I want it to do for me. Often
> the problem is that the default policy is simply too restrictive. On rare
> occasions I do actually file a bug report but almost always override the
> local policy anyway just to get on with the job.
>
> I hope this helps.

Hello James,
Thank you very much for the sharing. It's very informative.
--
Fajar Priyanto | Reg'd Linux User #327841 | Linux tutorial
http://linux2.arinet.org
22:12:49 up 2:45, 2.6.22-14-generic GNU/Linux
Let's use OpenOffice. http://www.openoffice.org
The real challenge of teaching is getting your students motivated to learn.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-23-2008, 10:40 PM
Florian Diesch
 
Default

"Steve Lamb" <grey@dmiyu.org> wrote:

> On Thu, May 22, 2008 8:13 am, Florian Diesch wrote:
>> "Steve Lamb" <grey@dmiyu.org> wrote:
>>> Nope. Because sudo certainly isn't needed on a single-user system.
>
>> If you don't want to work as root all the time you really want some
>> simple way to run a command as root. Using sudo instead of su makes
>> it a little bit easier as you don't have to remember two passwords.
>
> There isn't many times that I want to run *a* command as root. Often I
> want to run a *sequence* of commands which require the elevated
> privileges of root to remain for the entire sequence.

For me it's different, usually I'm using sudo for just one command
(or have aliases for the more frequently used sequences).

For most GUI-only users sudo (or its frontends like gksudo) is what
they want: GUI for calls from the menu, sudo for copied CLI commands.


> sudoing to root and suing to root is functionally identical thus
> sudo is not needed.

Functionally sudo is a superset of su



>> By default Ubuntu gives sudo access to everyone in the admin group. No
>> editing needed in your example.
>
> Presumes everyone is going to be in the admin group. The point of sudo
> is limiting elevated privileges to specific commands. Since that is
> going to be unique per user editing will be required.

Per default it just all or nothing, like su. having all the admin
users in the admin group seems to be sensible.


> Look, I'm not saying that sudo should be removed or that the Ubuntu use
> of sudo isn't convenient in some cases. I am just pointing out that as
> an example by Derek of a configuration tool "doing the right thing" it
> is spurious precisely because it isn't needed in the vast majority of
> installs where such niceties would be "needed".

I disagree with Derek in most points but here he's IMHO right: Maybe
it's not what the vast majority needs, but it's fine for the vast
majority, even if something less flexible would be fine, too.


Sometimes GUI front ends or automatic config tools do the right thin
for the vast majority. But of course there should be something for the
minorities, too.


Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 10:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org