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

Dave Airlie wrote:
> On Thu, 2008-07-17 at 18:15 -0500, Arthur Pemberton wrote:
>> On Thu, Jul 17, 2008 at 6:00 PM, Dave Airlie <airlied@redhat.com> wrote:
>>> Even so, don't let the user know, clearly they won't do the right thing,
>>> and you end up training them with the wrong behaviour. stop thinking of
>>> the user being someone who knows or cares what a policy/selinux or an
>>> exemption is.
>> While I agree with your statement as is, it is my unverified suspicion
>> that 'fedora user' is significantly different from 'user'.
>>
>> Thankfully, Fedora is not Ubuntu, and I may be idealistic, but I think
>> we may be able to expect a bit more from the average Fedora user...
>>
>> which leads me to another idea. Would probably be great if we could
>> have all AVCs copied easily to a central machine for those who use
>> Fedora in enterprise type environments.
>
> You know you just contradicted yourself
>
> If we want Fedora and by inheritance RHEL/CentOS to be useable on
> enterprise desktops or even consumer desktops we cannot assume we know
> what a "Fedora user" is. So we shouldn't be basing any decisions on the
> fact we might think a Fedora user is inherently smarter than an Ubuntu
> user.
>
>
>> - Emplyee A does something acceptable, encounters and AVC
>> - AVC reported to sysadmin
>> - Auto fix attempts fail
>> - request denied
>> - sysadmin reviews, decided to allow all such AVCs
>>
>> then
>>
>> - Emplyee A does same acceptable thing, encounters and AVC
>> - AVC reported to sysadmin
>> - activity found whitelisted
>> - auto fix tool allows
>
> For Enterprise desktops and RHEL something like that is what I would
> rather see. For non sysadmin maintained desktop, a community AVC dump
> with some responsible person who can allow/disallow things.
>
> Eventually the policy would be updated of course and rolled out.
>
> Dave.
>
Managed desktops in RHEL/Centos should not even be running sealert these
messages should be going to a centralized location for the sysadm to
monitor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiAkvUACgkQrlYvE4MpobOk9ACbBKW5Ixynkl r6RYSiYmQbgpb2
bt4An3+Javb+yz3D5prGRQK+3EuSrv18
=kJIc
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

Arthur Pemberton wrote:
> On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie <airlied@redhat.com> wrote:
>> On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote:
>>> - Autofix seems like a good idea
>>> - Perhaps Exempt button should only appear, if AutoFix doesn't work
>>> (not sure how to detect that)
>>> - To avoid a system user clicking Exempt, perhaps Exempt should only
>>> exempt the application only this time. i.e., when the application is
>>> launched again, it will generate a selinux warning again. That way,
>>> the user still reports the issue to get it properly fixed, but at the
>>> time, has the tools to get his work done and his apps running when he
>>> needs them
>>>
>> NO NO NO ... DOING IT WRONG.
>>
>> Don't ever ask the user for this kind of info, it would be better to go
>> ping a remote server and download a newer policy than ask the user.
>
> Well I think in his suggested use case, he's assuming a genuine bug in
> the policy which hasn't yet been fixed.
>
>
>> The user is not going to have a freaking clue wtf exempting means.
>
> Agreed
>
>> Didn't you guys see the Mac vs Windows ADs on TV?
>
> That came to mind, was kinda scary.
>
>
>> kerneloops does it right, opt in, send somewhere useful, next step if
>> somewhere useful has seen the AVC and we knows its safe, maybe send
>> something back saying continue and ignore, but don't involve the user in
>> the mess other than asking for opt-in.
>
> This may be a good idea. Have the service make a decision to continue
> deny on temporarily allow based on available knowledge from the
> server.
>
> How much private info if any would be in the average AVC?
>
Hostname, filename, potentially username, rpm information. What apps
they are running.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiAlIQACgkQrlYvE4MpobNqnACgv8xf7VjaM7 xG2oZnge4Lf6Ya
gwcAnAvi3UyIjC7ryCrHxKGTa1H6cc7D
=M+Nj
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

Daniel J Walsh wrote:
> Arthur Pemberton wrote:
>> On Thu, Jul 17, 2008 at 5:53 PM, Dave Airlie <airlied@redhat.com> wrote:
>>> On Fri, 2008-07-18 at 00:07 +0300, Ahmed Kamal wrote:
>>>> - Autofix seems like a good idea
>>>> - Perhaps Exempt button should only appear, if AutoFix doesn't work
>>>> (not sure how to detect that)
>>>> - To avoid a system user clicking Exempt, perhaps Exempt should only
>>>> exempt the application only this time. i.e., when the application is
>>>> launched again, it will generate a selinux warning again. That way,
>>>> the user still reports the issue to get it properly fixed, but at the
>>>> time, has the tools to get his work done and his apps running when he
>>>> needs them
>>>>
>>> NO NO NO ... DOING IT WRONG.
>>>
>>> Don't ever ask the user for this kind of info, it would be better to go
>>> ping a remote server and download a newer policy than ask the user.
>> Well I think in his suggested use case, he's assuming a genuine bug in
>> the policy which hasn't yet been fixed.
>
>
>>> The user is not going to have a freaking clue wtf exempting means.
>> Agreed
>
>>> Didn't you guys see the Mac vs Windows ADs on TV?
>> That came to mind, was kinda scary.
>
>
>>> kerneloops does it right, opt in, send somewhere useful, next step if
>>> somewhere useful has seen the AVC and we knows its safe, maybe send
>>> something back saying continue and ignore, but don't involve the user in
>>> the mess other than asking for opt-in.
>> This may be a good idea. Have the service make a decision to continue
>> deny on temporarily allow based on available knowledge from the
>> server.
>
>> How much private info if any would be in the average AVC?
>
> Hostname, filename, potentially username, rpm information. What apps
> they are running.
One other concern about report this AVC upstream, is a lot of these
avc's are handled properly by the troubleshooter. As an example the
ldap query about the mislabled file. Some of the plugins currently have
a please bugzilla this context while others are pretty sure they know
the problem. So we maybe want to have the report this upstream button,
only show up when setroubleshoot is baffled.

A lot of bugzilla's I get cut and paste the setroubleshoot window and
then I respond by saying "Do what the troubleshouter told you to do!"
Closed Not a Bug.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiAlqkACgkQrlYvE4MpobP8CACgsXuUINAzvq kZKOSDN/mqF3Ip
56AAoOXEga5M8UyxlVYzcZKquP1C8dsb
=pDkk
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Daniel J Walsh wrote:
...

the problem. So we maybe want to have the report this upstream button,
only show up when setroubleshoot is baffled.

A lot of bugzilla's I get cut and paste the setroubleshoot window and
then I respond by saying "Do what the troubleshouter told you to do!"
Closed Not a Bug.


I would say that generally, the user has no idea what might have
suddenly caused the visible denial. eg no recent system changes {ie
config files}, updates {the tool could mention which rpm installs /
updates have been performed since useful period ago} etc. So having the
tool suggest they need to run a sort of "let this happen anyway" command
should be considered risky, ie maybe something has got to the point
where an untrained {selinux} user will be allowing bad things to happen.


That's pretty much like the exempt/fix me IMHO. If se-t-s says that I
could make it not object by doing X, should I just do it, or is it
potentially telling me to do something that would allow the sort of
security breakthrough that selinux is trying to stop in the first place ?


It could be an improvement if the se-tools notice an selinux denial to:
download new policy if available, applies updated policy, relabel,
verifies disk files, before suggesting that the user start performing
security altering commands.


Also, if the selinux note could capture the offending command eg was a
gui click, a file copy, a script, a cron task {with params}, might it
then be possible to cause a reissue of the triggering command after a
policy update, so that a fix can be confirmed as actually correcting the
issue.


There could be additional help put into common selinux denials caused by
out-of-repo packages like vmware - where the tell tale signs could
trigger a message like "the installation of a third party application
like X may have modified the file context of /etc/blah in a way that
disrupted the correct labelling of the file. If you know that you have
recently installed X, you will need to fix the file context by ..."
That would give enough information for a user to confidently apply the
se-t-s command.


se-t-s could also attempt to rate the risk of performing the suggested
command ?


DaveT.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Casey Dahlin wrote:
- There should be more graphical tools for manipulating policy itself.
The user should be able to see a list of local policy exceptions they
have made.
And a button to disable one/all exceptions so we might see if the issue
has been resolved at the policy publishing level, and once we see that
we no longer get the AVC, a button to revert the exception.


DaveT.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

David Timms wrote:
> Daniel J Walsh wrote:
> ...
>> the problem. So we maybe want to have the report this upstream button,
>> only show up when setroubleshoot is baffled.
>>
>> A lot of bugzilla's I get cut and paste the setroubleshoot window and
>> then I respond by saying "Do what the troubleshouter told you to do!"
>> Closed Not a Bug.
>
> I would say that generally, the user has no idea what might have
> suddenly caused the visible denial. eg no recent system changes {ie
> config files}, updates {the tool could mention which rpm installs /
> updates have been performed since useful period ago} etc. So having the
> tool suggest they need to run a sort of "let this happen anyway" command
> should be considered risky, ie maybe something has got to the point
> where an untrained {selinux} user will be allowing bad things to happen.
>
> That's pretty much like the exempt/fix me IMHO. If se-t-s says that I
> could make it not object by doing X, should I just do it, or is it
> potentially telling me to do something that would allow the sort of
> security breakthrough that selinux is trying to stop in the first place ?
>
> It could be an improvement if the se-tools notice an selinux denial to:
> download new policy if available, applies updated policy, relabel,
> verifies disk files, before suggesting that the user start performing
> security altering commands.
>
> Also, if the selinux note could capture the offending command eg was a
> gui click, a file copy, a script, a cron task {with params}, might it
> then be possible to cause a reissue of the triggering command after a
> policy update, so that a fix can be confirmed as actually correcting the
> issue.
>
> There could be additional help put into common selinux denials caused by
> out-of-repo packages like vmware - where the tell tale signs could
> trigger a message like "the installation of a third party application
> like X may have modified the file context of /etc/blah in a way that
> disrupted the correct labelling of the file. If you know that you have
> recently installed X, you will need to fix the file context by ..."
> That would give enough information for a user to confidently apply the
> se-t-s command.
>
> se-t-s could also attempt to rate the risk of performing the suggested
> command ?
>
> DaveT.
>

Well I would argue that setroubleshoot does a lot of this, although it
has very limited information. Giving the tool the ability to check if a
newer version of selinux-policy would fix the issue would be a huge step
forward. I think understanding that vmware hosed up the /etc/services
file labeling, is a tougher problem. Maintaining a database of
offending third party apps would be tough to maintain, and when vmware
fixes the problem we would need to make sure setroubleshooter no longer
blamed them. :^)

One of the goals of the new doc writer will be to improve the text in
the setroubleshooter, to be more humanly readable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiAptkACgkQrlYvE4MpobN7rgCg6EOPEQurXL pOv2xUmTXfi6/t
HIQAoJY/CV5dlKzNsH5mg+uXqiDWsFqw
=7epY
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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

Arthur Pemberton wrote:
> On Fri, Jul 18, 2008 at 9:03 AM, David Timms <dtimms@iinet.net.au> wrote:
>> Daniel J Walsh wrote:
>> ...
>>> the problem. So we maybe want to have the report this upstream button,
>>> only show up when setroubleshoot is baffled.
>>>
>>> A lot of bugzilla's I get cut and paste the setroubleshoot window and
>>> then I respond by saying "Do what the troubleshouter told you to do!"
>>> Closed Not a Bug.
>> I would say that generally, the user has no idea what might have suddenly
>> caused the visible denial. eg no recent system changes {ie config files},
>> updates {the tool could mention which rpm installs / updates have been
>> performed since useful period ago} etc. So having the tool suggest they need
>> to run a sort of "let this happen anyway" command should be considered
>> risky, ie maybe something has got to the point where an untrained {selinux}
>> user will be allowing bad things to happen.
>>
>> That's pretty much like the exempt/fix me IMHO. If se-t-s says that I could
>> make it not object by doing X, should I just do it, or is it potentially
>> telling me to do something that would allow the sort of security
>> breakthrough that selinux is trying to stop in the first place ?
>>
>> It could be an improvement if the se-tools notice an selinux denial to:
>> download new policy if available, applies updated policy, relabel, verifies
>> disk files, before suggesting that the user start performing security
>> altering commands.
>
> Would this really something that could be done without getting
> permission from a user?
>
>
>
No but it would be cool if it could say, this bug is already fixes in
the lates selinux-policy available in updates. Please
yum -y update selinux-policy-targeted


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

iEYEARECAAYFAkiA0IUACgkQrlYvE4MpobN4zwCg6t9FvHIPek e3SHF4WuxzW0vi
SfQAoMhaEFv00pnKFuxcgIy0ISAYmysn
=VTtw
-----END PGP SIGNATURE-----

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Fri, 2008-07-18 at 13:19 -0400, Daniel J Walsh wrote:

> No but it would be cool if it could say, this bug is already fixes in
> the lates selinux-policy available in updates. Please
> yum -y update selinux-policy-targeted
>
Or even better, integrate with PackageKit and offer to install it for
them!

Stewart

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 17 Jul 2008, Daniel J Walsh wrote:

> We have just added a new access called open. Before we had only
> read/write. You could get read/write errors from open file descriptors
> being passed around as explained above. useradd dwalsh > ~/myhome will
> generate an Read/write avc. This is not some thing to worry about,
> however if named suddenly got an "open" avc on user_home_t you know you
> have a problem. Since named should never be opening files in the homedir.

Btw, for those that missed it, I covered the new open perm here:
http://james-morris.livejournal.com/31714.html

One effect of this is that I think you could say it makes SELinux a
lot more Unix-y.


- James
--
James Morris
<jmorris@namei.org>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Fri, 18 Jul 2008 09:12:09 -0400
Daniel J Walsh <dwalsh@redhat.com> wrote:

> A lot of bugzilla's I get cut and paste the setroubleshoot window and
> then I respond by saying "Do what the troubleshouter told you to do!"
> Closed Not a Bug.

.. if it knows what to do, but doesn't just do it, that would be a
bug ;-)

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list