Re: selinux??

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



BTW... Yes, you can disable SELinux. Once you have your work done, you can enable or keep it disabled, as you like it. 



Hope it helps, 
Sylvia 

On Tuesday, 26 January 2016, bruce <badouglas@xxxxxxxxx> wrote:
What the Heck???

So.. people who think/decide to just disable seLinux, instead of
diving in to "learn" it are just lazy????  Lord.. shaking my head..

How about.. some might be lazy..

Or, some have a bunch of different things to get accomplished, and
aren't looking to be a sysAdmin, so they want to (if possible) get to
the quickest way of getting their "project" working/tested.. And if
the "security/process" of X (in this case selinux) is in the way.. The
learning required to implement that gets shoved back. It's a
prioritization process for a bunch of people.

You have a limited amount of resources, you priortize and keep going.
And yeah, you realize that you might be cutting corners re security,
but you keep going.

And before people say, "you need to learn security, or you shouldn't
be writing apps!!".. not going to happen.

Implementing "good" secutiry, doesn't happen by spending a few hours
on a few sites. You eventually run into issues that "need to be
solved", etc.. which then adds time/effort/resources. And rightly so,
this is why you have skilled sysAdmin resources. But smaller projects
don't have the resources for this process.. so it becomes a matter of
prioritization/resource allocation..

And I say again.. I've been willing to pay hard $$$ for someone
willing to work with me on security.. No takers..!!!

So, please, no disparaging "laxy" remarks, ok!

Thanks!


On Mon, Jan 25, 2016 at 11:21 PM, Tim <ignored_mailbox@xxxxxxxxxxxx> wrote:
> Allegedly, on or about 25 January 2016, vendor@xxxxxxxxxxxxx sent:
>> Did you mean "hacked" or "attacked?"
>
> To me an attack is the attempt, a hack is they've succeeded.  They
> succeeded.  Though, to be fair, I didn't say it was Linux computer, but
> the principle is the same.  All computers are vulnerable, though in our
> case it's more the applications than the OS.  And if you take no steps
> to protect your system, or worse, take steps to remove protection, you
> lay yourself wide open.
>
>> The problem I see with selinux is that it is so user-unfriendly.
>> These kinds of things always seem easy and straightforward to someone
>> who knows it well.  That's the nature of skill, regardless of the kind
>> of skill it is.
>
> I see it no less user-friendly than other things.  I look at ACL (access
> control lists), and see them as a nightmare.  I can see them being used
> in security establishments, to control who can see or modify certain
> documents that need disseminating.  But not in general use.  I can't
> really imagine employee #54534624 writing a letter, then carefully
> considering a list of who can do what with their file (mutter, mutter,
> need to add my boss to read/write, my assistant to read/write, my
> technically hopeless other boss to read-only so he doesn't foul up my
> work, my co-workers to read-only, and I have to remember which of them
> are working on the same case...).
>
> Barring oversights and errors, SELinux generally does what it's supposed
> to do.  If I create a file in /var/www/html/ to be served, it
> automatically gets given the right contects to be served, as part of the
> process of *creating* a file at that location.  If I copy a file from
> somewhere to there, the same thing happens, the copy is a new creation,
> and gets the appropriate contexts for where it's created.  A confusing
> thing happens if you try to move a file, the original file contexts are
> moved along with the file, and they're probably going to be wrong.  It's
> logical, but not obvious to the uninitiated.  Though it's not too hard
> to find out why, you just problem solve it like any other error that
> takes you by surprise.
>
> It's similar with file permissions.  Some people declare it too hard,
> and want to make everything rwxrwxrwx, and hang the consequences.  On a
> webserver, that (making everything world-writeable), or letting the
> webserver process own the files (making everything writeable by the
> server, and hence world-writeable), opens you up to all sorts of abuse,
> not just the destruction of that individual file.
>
>> That's what I think of when I read these discussions.  If someone is
>> struggling with something like this, they may seem like morons, but it
>> is usually someting *other* than simple supidity or laziness that is
>> the reason.  It's because the barrier to doing it is greater than the
>> perceived benefit.
>
> At times, but the tone of the thread indicates that laziness is an
> issue.
>
>> There is a truism that I remember being told about computer security a
>> long, long time ago that usability and technical security are
>> inversely related.  At some point, when you increase the technical
>> security enough, you will have made the system unusable to the point
>> that your users will simply start going around it simply to get their
>> work done.
>
> That's true on both counts.  Though I tend to feel that SELinux has met
> that balance at around the right place.
>
> While I have some sympathy for people who haven't yet learnt it, as they
> try to do something.  My efforts are towards learn it, don't bypass it.
> Just the same as well tell people don't do things as root - that's often
> the root cause, pun intended, of all of these issues.  They do one dumb
> thing, then another on top of that, and have several compounded problems
> because they will not follow any advice.
>
> It's usually around this point that I bring up an analogy against people
> trying to do things on computers when they don't really know how, and
> stubbornly resist all efforts to learn:  I hope these people never get
> it into their head to half-arsedly learn first aid, and refuse to do
> something important because they don't want to.
>
>> ...[snip flash drive story]...
>
> I can understand that, and it's not a new story, either.  The need to do
> it is understandable.  The concept of doing it in isolation can be a
> required step.  If the drive manages to do something nasty, it only
> affects that one computer, which then gets sterilised before being
> allowed back on the network (if the operator knows that, and doesn't
> just plug it back in, regardless).
>
> We had similar issues with floppy discs.  Back when bootblock viruses
> were the common enemy, there was no/inadequate protection against them.
> The only way to stop the spread, was a cold boot in between, and using a
> system that booted from the disc in question.  That method was no good
> against an OS that had another disc-based OS running it.
>
>> The combination of security that ignores users and users that ignore
>> security gives you a system that has neither security nor usability.
>> And simply calling users morons will not solve this.
>
> I don't believe I've said that.  In this email I've certainly mentioned
> laziness, because the evidence points that way.
>
> As a general rule, on a user-level, SELinux doesn't get even thought
> about, here.  It's in the background, and doesn't get in the way.  If
> you're running services, then it rightly does become something you need
> to know about managing.
>
> But what particularly gets my goat, it someone who's a programmer
> developing things telling me that SELinux is too hard to deal with.  Too
> hard?  Compared with what?  Writing software?!  Jeez, you've got much
> harder work, *there*.  And, as far as I'm concerned, programmers being
> hit with the big hammer that says, you have to write data in proper
> locations, you can't just read any file you like on the system, you
> can't just serve out files from any ad-hoc locations, is only a good set
> of conditions to start imposing on so-called programmers.  Bring on the
> software that pokes them with a sharp stick for doing things that allows
> them to create buffer-overflow errors.  We could save the entire world a
> whole lot of grief if programmers started paying attention to getting
> that one bit of programming right.
>
>> I love KDE, but frankly, it is collapsing under it's own complexity.
>
> I can't say I've ever liked it.  It has the Fisher-Price toy look like
> XP had, and a gazillion configuration options that I do not like the
> defaults, and it's always been that way (ever since I saw it, a
> gazillion configuration options).  Coming from an Amiga user background,
> I've never agreed with what people said about Gnome looking like
> Windows, no KDE does.  Gnome looked far more old Mac-like.
>
> The other thing that peeved me about KDE (and I can see this thread is
> going to open a new can of worms), is the naming of all programs
> starting with a K followed by a name that seems purely random (regarding
> what the program actually did).  Not only making it hard to locate
> software appropriate to your task, but confusingly k-naming things like
> kernal-things got k-named (kmod, anyone? - a kernel module, or a KDE
> something).
>
>>  Selinux is just another exmple.  I used to like linux because it made
>> sense.  Now it seems that it's little different than Windows sometimes
>> -- opaque, overly complex, and unfriendly.
>
> I don't think anything compares with the hideousness of Windows.  So
> much of it is secret business, and I don't just mean closed-source.
> Resolving some whacko fault involves delving into the registry, adding
> things with sixteen hexadecimal numbers which mean nothing to no-one,
> that are only documented on hacking sites, or incomprehensible gibberish
> on the Microsoft that refers to two versions of Windows ago, warns
> against doing it on your release, yet the Microsoft search engine
> provides it as your solution.
>
> We now return you to your regular programming, from
> alt.computers.help.me.commit.die.quickly
>
> --
> [tim@localhost ~]$ uname -rsvp
> Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
>
> Boilerplate:  All mail to my mailbox is automatically deleted, there is
> no point trying to privately email me, I only get to see the messages
> posted to the mailing list.
>
> Lucky for you I typed this, you'd never be able to read my handwriting.
>
>
>
> --
> users mailing list
> users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux