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

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 01-03-2008, 07:59 PM
Jesse Keating
 
Default selinux rant, compressed version (Was kernels won't boot)

On Thu, 03 Jan 2008 15:56:22 -0500
David Zeuthen <david@fubar.dk> wrote:

> Sure, granted. I wasn't really ranting at the .rpm or .deb people
> here.
>
> (However, no one prevents you from using SELinux in permissive mode
> during installs or live cd creation and then relabel the fs at the
> end. Heck at least for the latter I'm pretty sure you can't even use
> enforcing mode because the SELinux policy is so draconian as part of
> it's complexity)

Yeah, we have to use permissive at least, or else things fail.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-03-2008, 08:01 PM
David Zeuthen
 
Default selinux rant, compressed version (Was kernels won't boot)

On Thu, 2008-01-03 at 15:48 -0500, Jesse Keating wrote:
> On Thu, 03 Jan 2008 15:43:26 -0500
> David Zeuthen <david@fubar.dk> wrote:
>
> > Typical responses:
> > - "rpm cannot handle SELinux policy": <- bullshit; it's not much
> > different from other file meta data; do we store file modes and
> > permissions centrally too? No.
>
> I don't know where you're getting this "typical" response from. The
> problem isn't rpm, the problem is selinux itself, not allowing rpm to
> write out files that have a context it doesn't know about (yet),

Also, one obvious solution here is to install the selinux policy before
files are copied; much like you create a daemon user in %pre. Or if %pre
isn't early enough, invent another tag or whatever. Point is: you can't
entirely blame this on the SELinux people; getting things like rpm to
work with selinux actually requires a two-way conversation - something
that some companies can't figure out to make happen :-/

David


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-03-2008, 09:07 PM
Daniel J Walsh
 
Default selinux rant, compressed version (Was kernels won't boot)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Zeuthen wrote:
> On Thu, 2008-01-03 at 14:45 -0500, Dimi Paun wrote:
>> On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote:
>>> I'm not running SELinux enforcing mode on any of my machines..
>> That's too bad -- it's hard to gage the usability of a system
>> without it on, since it is enabled by default for most people.
>
> Well, the kernel bits of SELinux is great. The user space bits never
> ever worked for me; neither as a user, nor RPM package maintainer and
> definitely not as an upstream developer of highly modular software that
> is designed to be locked down (e.g. hald and it's helper processes)
>
> Some problems from a 50,000 feet point of view
>
> - the policy is way too complicated; really, I think it's kinda futile,
> at this point, to attempt to lock down bits that are not even
> network-facing.
>
> As a result someone decided "oh, we're just going to let people turn
> of it". And this is where we are now. Total cop out. Might as well
> not ship it.
>
> Seriously. Just go ahead and look at the policy. No wonder it often
> doesn't work given it's so complex.
>
> - the policy is centrally maintained; e.g. the maintainer of the policy
> for hald (Dan Walsh) and, hey, all of the policy often have to guess
> how to lock things down and often, despite Dan being a great
> engineer, these guesses are just wrong. Seriously, no one can blame
> Dan for this - you cannot expect a single person to know all the
> kinks of all the software in Fedora.
>
> -> Ideally every upstream project can maintain it's own policy. That
> has the nice side effect of, gosh, teaching other distributions
> about the benefits of MCA.
>
> -> If upstream don't want to include SELinux policy, just include
> it as a patch in the RPM
>
> Typical responses:
> - "rpm cannot handle SELinux policy": <- bullshit; it's not much
> different from other file meta data; do we store file modes and
> permissions centrally too? No.
>
> - "uh, then you would have deps on policy": Like, for example, the
> policy for hald would depend on the policy for, say, dbus. Not
> a problem, the real world contains dependencies already and most
> these deps are handled just fine already by the upstream
> projects.
>
> I'm not even going to go into the language used for defining policy.
>
> In short, SELinux just doesn't work for me. I'm not denying it may work
> well on a tightly-controlled servers where features never change (e.g.
> RHEL).
>
> David
>
>
Well there are several problems with allowing the individual maintainers
manage their own policy.

#1 they won't.
#2 when they do, they do a very bad job of it. Or basically just end up
with unconfined_t.
#3 The tools are too slow. Having 100 semodule -i will cause the
installation to take for ever.
#4 Interaction between confined domains does not work well when multiple
maintainers writing policy.
sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver,
pyzor ... All interact in very complex ways.
#5 conflicts on file_context directories/files

David, You are writing an application that is trying to do things on
behalf of the user as root. These activities will cause conflicts and
need to be well controlled. So you are likely to run into problems with
SELinux.

Jesse, what problems are you seeing that needs to run in permissive
mode? I know about the chroot environments and there is not a good
answer to this. Placing of the file context down without loading the
SELInux policy would help in this environment. But we would still have
problems with applications running in post install, not getting the
correct context.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkd9XKQACgkQrlYvE4MpobNNxgCg6RQ5obJYQl ybtl275oLfpdD1
pkwAoKOpjXe5mubk7MsUpBRNE6k1YGzp
=jfZz
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-03-2008, 09:16 PM
Jesse Keating
 
Default selinux rant, compressed version (Was kernels won't boot)

On Thu, 03 Jan 2008 17:07:33 -0500
Daniel J Walsh <dwalsh@redhat.com> wrote:

> Jesse, what problems are you seeing that needs to run in permissive
> mode? I know about the chroot environments and there is not a good
> answer to this. Placing of the file context down without loading the
> SELInux policy would help in this environment. But we would still
> have problems with applications running in post install, not getting
> the correct context.

What I've seen is if selinux is in enforcing part of the compose
process will fail in such a way that selinux will default to /off/ for
the resulting composed media (funny eh?). I think it had something to
do with a denial, but the memory is hazy. But since most of my
composing involves A) mock for the initial compose environment (that's
one chroot) and B) buildinstall itself creating an install root to
populate stage1/2 contents (that's two chroots) I kind of feel I'm out
in left field.

--
Jesse Keating
Fedora -- All my bits are free, are yours?
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-03-2008, 09:46 PM
David Zeuthen
 
Default selinux rant, compressed version (Was kernels won't boot)

On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote:
> Well there are several problems with allowing the individual maintainers
> manage their own policy.
>
> #1 they won't.
> #2 when they do, they do a very bad job of it. Or basically just end up
> with unconfined_t.
> #3 The tools are too slow. Having 100 semodule -i will cause the
> installation to take for ever.
> #4 Interaction between confined domains does not work well when multiple
> maintainers writing policy.
> sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver,
> pyzor ... All interact in very complex ways.
> #5 conflicts on file_context directories/files

See.. cause and effect.. #1 and #2 are the effects of #3 and the fact
that the policy is way too big and the whole system is way too
complicated.

Besides.. I have asked probably more than ten times (both electronically
and in person) about maintaining the selinux policy for hal in the
_upstream_ tarball but I've always been told that it's not possible or
I've been told to wait. In the meantime it's business as usual; things
are broken and people turn off SELinux.

Here's a challenge: Send me a patch against the hal git repo and the
RPM spec with the SELinux bits... Then I'll be happy to maintain it;
including spending time on learning SELinux well enough to do a good
job. Is this even possible? Should it be possible?

> David, You are writing an application that is trying to do things on
> behalf of the user as root. These activities will cause conflicts and
> need to be well controlled. So you are likely to run into problems with
> SELinux.

Sigh. Do you really honestly think this is a good answer for upstream
maintainers that are _willing_ to help?

David


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-04-2008, 12:17 AM
Steve Grubb
 
Default selinux rant, compressed version (Was kernels won't boot)

On Thursday 03 January 2008 17:46:51 David Zeuthen wrote:
> > #1 they won't.
> > #2 when they do, they do a very bad job of it. *Or basically just end up
> > with unconfined_t.
> > #3 The tools are too slow. *Having 100 semodule -i will cause the
> > installation to take for ever.
> > #4 Interaction between confined domains does not work well when multiple
> > * maintainers writing policy.
> > sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver,
> > pyzor ... All interact in very complex ways.
> > #5 conflicts on file_context directories/files
>
> See.. cause and effect.. #1 and #2 are the effects of #3

I don't think this is true at all. semodule being slow has nothing to do with
people thinking about security. It takes time and testing a lot of variations
of config options to arrive at what the application is supposed to do. Some
people also may not recognize when an avc means the code needs to change
instead of allowing the behavior.

I think that #4 is the real killer. Dan did a major reworking of policy in F8
to merge what was the strict policy with targeted. The way that roles work
was beefed up. If this had to be coordinated with every single package
maintainer, it probably wouldn't have gotten done as quickly or as uniformly.

> and the fact that the policy is way too big and the whole system is way too
> complicated.

This is more a fact of it telling you that software in general is complicated.
SE Linux is describing the allowed behavior at a level that is slightly above
the syscall level. If the syscalls a program makes change, the policy may
need reworking.

This is probably why you run into problems frequently as you are developing
and testing new code (with new syscalls) that is central to many programs.

I wonder if a tool could be developed to do something like nmap and compare
current syscalls with an older version. It wouldn't be able to track resource
usage (files/sockets), which is another thing selinux regulates, but it could
tell you a little about if a new version is going to have problems. If we
could simply tell that a new package required policy changes, that would be
half the battle.

-Steve

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-04-2008, 02:28 AM
Andrew Farris
 
Default selinux rant, compressed version (Was kernels won't boot)

Steve Grubb wrote:
> I wonder if a tool could be developed to do something like nmap and compare
> current syscalls with an older version. It wouldn't be able to track resource
> usage (files/sockets), which is another thing selinux regulates, but it could
> tell you a little about if a new version is going to have problems. If we
> could simply tell that a new package required policy changes, that would be
> half the battle.

I don't know if that would be possible, but I think that would be beneficial and
expedite getting the correct policy changes in place for testing updates as well
as new packages. One major issue with testing these packages with enforced
selinux is that you often cannot get the program to operate even enough to
'test' it, and it can take quite awhile to get the policy change so you can then
continue trying enforcing mode. That tiring cycle is probably why so many
testers just toggle it off, and then it just takes longer to find all the
denials for test packages.

I suppose the maintainer just doing a cursory selinux test of their own before
getting package builds dropped into rawhide might help... I'm sure many do but
it would seem that some don't. Just getting a BZ filed with the denials asap is
important.

--
Andrew Farris <lordmorgul@gmail.com> <ajfarris@gmail.com>
gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 01-11-2008, 02:05 PM
Daniel J Walsh
 
Default selinux rant, compressed version (Was kernels won't boot)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Zeuthen wrote:
> On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote:
>> Well there are several problems with allowing the individual maintainers
>> manage their own policy.
>>
>> #1 they won't.
>> #2 when they do, they do a very bad job of it. Or basically just end up
>> with unconfined_t.
>> #3 The tools are too slow. Having 100 semodule -i will cause the
>> installation to take for ever.
>> #4 Interaction between confined domains does not work well when multiple
>> maintainers writing policy.
>> sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver,
>> pyzor ... All interact in very complex ways.
>> #5 conflicts on file_context directories/files
>
> See.. cause and effect.. #1 and #2 are the effects of #3 and the fact
> that the policy is way too big and the whole system is way too
> complicated.
>
> Besides.. I have asked probably more than ten times (both electronically
> and in person) about maintaining the selinux policy for hal in the
> _upstream_ tarball but I've always been told that it's not possible or
> I've been told to wait. In the meantime it's business as usual; things
> are broken and people turn off SELinux.
>
> Here's a challenge: Send me a patch against the hal git repo and the
> RPM spec with the SELinux bits... Then I'll be happy to maintain it;
> including spending time on learning SELinux well enough to do a good
> job. Is this even possible? Should it be possible?
>
>> David, You are writing an application that is trying to do things on
>> behalf of the user as root. These activities will cause conflicts and
>> need to be well controlled. So you are likely to run into problems with
>> SELinux.
>
> Sigh. Do you really honestly think this is a good answer for upstream
> maintainers that are _willing_ to help?
>
> David
>
>
I have build a spec file and included the current rawhide sources for
both policy kit and hal. As soon as you are ready to ship them I will
move them to update status in the selinux-policy package.

If you need help building the policy or writing policy, please you
know how to reach me. :^)

If other maintainers are interested in shipping their own policy, I will
make it available.

Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkeHhcQACgkQrlYvE4MpobNGwACgnBukrbuALt gu8/M3Uy1gB3Y4
SrkAn0kM5y0IeGosdRrs9JoTebino+Px
=H2NC
-----END PGP SIGNATURE-----
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 06:47 PM.

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