subject:"Re\: Prioritizing \~\/.local\/bin over \/usr\/bin on the PATH"

On Fri, Jun 22, 2018 at 07:24:54PM +0200, Björn Persson wrote:
> Till Maas wrote:
> > I do not see any reason why a user would put something in ~/bin that
> > would mask something in /usr/bin except to actually mask the binary. It
> > is the same with other user configuration, anyone expects ~/.ssh/config
> > to override /etc/ssh/ssh_config instead of the other way round.
> 
> It could happen by accident. A user might put a program in ~/bin that
> happens to have the same name as one in /usr/bin that the user is
> unaware of, and it might break other programs which call that command
> without a full pathname. Editing ~/.ssh/config affects only SSH, and
> isn't likely to break something unrelated.
> 
> That's one reason why I'm not convinced that this change is a good
> idea. It obviously has nothing to do with security though. It's a
> matter of safety, which is different from security.

In your opinion, how does the user act nowadays when something in
/usr/bin masks their tool that they installed in ~/bin? I would assume
that they will change the path, since installing the tool there is what
they wanted. Making it hard for users to achieve their goals usually
does not stop them. Also a tool with a same name in /usr/bin might also
break another user's tool that expects the user version to be available
in the PATH. I do not see how this would be better. And it might also
happen with aliases or functions that users would configure in
~/.bashrc. I know that bash-completion using the _* namespace broke a
lot of shortcuts that I used (and I still think it is sad that this easy
to use prefix (at least on a QWERT* keyboard) was made unusable, even
though these are identifiers nobody needs to type).

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3JRVHYDX2HQ7NRIAZBLP54RMTYJQDQUV/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Fri, Jun 22, 2018 at 05:01:38PM +0100, Tomasz Kłoczko wrote:
> On Fri, 22 Jun 2018 at 13:36, Till Maas  wrote:
> [..]
> > > The attacker could have looked up the exploit on the web.
> >
> > If it is a public exploit, then it is usually fixed by updates,
> > especially if the impact is that big. A user not installing
> > security updates is a scenario I consider not worth to explore, since
> > there might be all kinds of serious vulnerabilities.
> 
> Just FTR.
> If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on
> the $PATH it will be possible to control over ~/.local/bin/id (and/or
> many more similar commands) what happens on begin of the user login
> session. None of the packages updates (except that one which will
> remove ~/.local/bin/ from the $PATH) would be able to stop damage ones
> done.
> 
> Would you consider now classify such change as serious vulnerability
> introduction?

No, the vulnerability is whatever allowed attackers to get write access
to $HOME. And there would be a lot more changes to $HOME or other paths
in a real-world attack that an update could not fix. Also I guess most
attacks target information, computing power or network access and there
is no way to revoke this with an update after the attack was successful.
And the best practice to cleanup after an attack is to reinstall from
known-good sources.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3FUF76JH5CTAGVXD4ZJWKCCAQNXOEEY5/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-22 Thread Björn Persson

Till Maas wrote:
> I do not see any reason why a user would put something in ~/bin that
> would mask something in /usr/bin except to actually mask the binary. It
> is the same with other user configuration, anyone expects ~/.ssh/config
> to override /etc/ssh/ssh_config instead of the other way round.

It could happen by accident. A user might put a program in ~/bin that
happens to have the same name as one in /usr/bin that the user is
unaware of, and it might break other programs which call that command
without a full pathname. Editing ~/.ssh/config affects only SSH, and
isn't likely to break something unrelated.

That's one reason why I'm not convinced that this change is a good
idea. It obviously has nothing to do with security though. It's a
matter of safety, which is different from security.

Björn Persson

pgpNNmJlUq98I.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6HNKT2634Y4VWC52KYTEMFWPJST6ETAY/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-22 Thread Björn Persson

Tomasz Kłoczko wrote:
> Just FTR.
> If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on
> the $PATH it will be possible to control over ~/.local/bin/id (and/or
> many more similar commands) what happens on begin of the user login
> session. None of the packages updates (except that one which will
> remove ~/.local/bin/ from the $PATH) would be able to stop damage ones
> done.
> 
> Would you consider now classify such change as serious vulnerability
> introduction?

If you state a falsehood again and again it will eventually become true?

Björn Persson


pgpRkTK3_EirR.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T5KBVFSRR46O6W5SEI3GU4GGOOINBDQR/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-22 Thread Matthew Miller

On Fri, Jun 22, 2018 at 05:01:38PM +0100, Tomasz Kłoczko wrote:
> If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on
> the $PATH it will be possible to control over ~/.local/bin/id (and/or
> many more similar commands) what happens on begin of the user login
> session. None of the packages updates (except that one which will
> remove ~/.local/bin/ from the $PATH) would be able to stop damage ones
> done.

It does seem like /etc/profile and others should be updated to use full
paths for these commands.

I don't think this particularly expands the attack surface in any
meaningful way, though.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BBJIOFDG7JYD2B53HJYAMHW446HZJS7N/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-22 Thread Tomasz Kłoczko

On Fri, 22 Jun 2018 at 13:52, Till Maas  wrote:
[..]
> No, it does not change everything as attackers can also just copy
> desktop files with other Exec-Keys to
>
> /home/till/.local/share/applications, for example like this:
>
> sed -e s,Exec=.*,Exec=xmessage\ pwned,
> /usr/share/applications/firefox.desktop >
> ~/.local/share/applications/firefox.desktop
>
> There is no need to drop something in the path to manipulate desktop
> files/the applications that are started (I verified this with Gnome on
> Fedora 28). Please stop with these false claims.

Yep, It is known. Few people have been trying to convince other people
to ignore any Exec lines in ~/.local/share/applications/*desktop files
to allow icons or menu entries texts changes still possible or at
least make this as the desktop settings option. So far no success.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2O2GXACHISCCAFXXCMWZ4G4G6H637LVS/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-22 Thread Tomasz Kłoczko

On Fri, 22 Jun 2018 at 13:36, Till Maas  wrote:
[..]
> > The attacker could have looked up the exploit on the web.
>
> If it is a public exploit, then it is usually fixed by updates,
> especially if the impact is that big. A user not installing
> security updates is a scenario I consider not worth to explore, since
> there might be all kinds of serious vulnerabilities.

Just FTR.
If Fedora maintainers will decide to put ~/.local/bin over /usr/bin on
the $PATH it will be possible to control over ~/.local/bin/id (and/or
many more similar commands) what happens on begin of the user login
session. None of the packages updates (except that one which will
remove ~/.local/bin/ from the $PATH) would be able to stop damage ones
done.

Would you consider now classify such change as serious vulnerability
introduction?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XMA24FNN3KHBUPNQAGWDGYVRJ32Z4LE4/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Mon, Jun 18, 2018 at 02:17:43PM +0100, Tomasz Kłoczko wrote:

> For example in case of have /usr/local/bin/id you can observe that
> gnome-terminal started from command line and GUI menu are altere.
> In other words this effect is literally spreads as well across most of
> the /usr/share/application/*desktop files (just grep those files for
> ^Exec=).
> Using in Exec= only binary name instead full path would be nothing bad
> .. however this mixed with currently used $PATH really changes
> everything!

No, it does not change everything as attackers can also just copy
desktop files with other Exec-Keys to

/home/till/.local/share/applications, for example like this:

sed -e s,Exec=.*,Exec=xmessage\ pwned,
/usr/share/applications/firefox.desktop >
~/.local/share/applications/firefox.desktop

There is no need to drop something in the path to manipulate desktop
files/the applications that are started (I verified this with Gnome on
Fedora 28). Please stop with these false claims.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4IT3C2JTRLTNI74UJYWXMTPY5QZNOZJT/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Sat, Jun 16, 2018 at 01:17:57PM -0400, Nico Kadel-Garcia wrote:

> * Stolen passwords from penetrated hosts, used for SSH connections.
> Copying a file to $HOME/.local/bin requires far less scripting and
> awareness of existing contents than editing of .bashrc or .profile
> that reveals timestamp changes of the edited file, and differs from
> system defaults. Since the contents of $HOME/.local/bin are not
> defined or definable, by its very nature, it's harder to audit.

The system default would be that they are empty or contain the files
that are put there by default. Not really harder to audit that a .bashrc
file. Also if you can use SSH to access the system, you can just execute
commands. If you can only copy files, why is copying content to ~/.i18n
less bad?

> * Fileshares of home directories. Many environments, especially
> university environments, use NFSv3 with quite general access. Welcome
> to write access to $HOME/ !!!  And $HOME/.local/bin is notably less
> apparent than $HOME/bin, due to the default lack of "ls" reporting of
> contents of "." prefaced directories, and of the difficulty of leaving
> security auditing to check .bashrc, .profile, etc.

Still, why would an attacker then copy something to these directories
instead of to ~/.i18n, or ~/.ssh/config or ~/.vimrc? Also if you want to
do a proper audit of all executables in the PATH the first step would be
to check the value of $PATH because this is something an attacker could
also change to any other value that would need to be checked. And once
you look at $PATH, ~/.local/bin is no longer hidden because it is in
plain sight there, even easier to spot when it is at the beginning.

> Does that give you enough examples of unnecessarily vulnerable vectors
> opened by default by the casual assumption that "ohh, they could get
> in another way, so I don't have to worry about the hole *I* am
> suggesting opening up!!!"

No, in your examples $HOME would be compromised anyhow already.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6ADYSLRDQ72VOPLMPMCN26ZSOJUBIWCV/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Fri, Jun 15, 2018 at 06:56:16PM +0200, Alois Mahdal wrote:
> 
> 
> On 06/15/2018 11:24 AM, Till Maas wrote:
> > ...]
> > 
> >> What I'm trying to say is that with these kinds of attack (like viruses,
> >> or exploits on massively accessed page), there is inevitably going to be
> >> some sort of economic decision on side of author affecting how "smart"
> >> they want the code to be.
> >>
> >> Thus, every little step you're making towards "easier" translates to
> >> dumber exploits being able to succeed.  Suddenly not just those that did
> >> 2 things but also those that did 1 thing.
> > 
> > So the assumption is to have a super sophisticated browser exploit for
> > which an attacker most likely spent several days to find it and then the
> > PATH setting will make it so much harder that the exploit will not
> > succeed? There are a lot more real challenges that attackers have to face.
> 
> The attacker could have looked up the exploit on the web.

If it is a public exploit, then it is usually fixed by updates,
especially if the impact is that big. A user not installing
security updates is a scenario I consider not worth to explore, since
there might be all kinds of serious vulnerabilities.

> I think you keep putting some kind of base standard on the hypothetical
> attacker and then your argument is "if they can do X then they can do
> Y".  Because we're both SW engineers, the relation between X and Y is
> obvious to us, so yeah, anybody who would do X would totally obviously
> also do Y.  Sure, we've been there so many times we don't even think
> about it.

This is a useful way to categorize security vulnerabilities because they
should allow an attacker to gain more privileges/possibilities/... And
if we assume that a system is secure because people do not know about
other possibilities, then it is security by obscurity which does not
work in practice.

> OTOH, I don't think that's the best way to think about security.  There
> are no standards.   The amount of code (dedicated to Linux) could
> totally be just that single line, writing the payload to .local/bin.
> By including the path in default $PATH, you are allowing also the
> on-bit-dumber attack to succeed (... now with all Fedora users, yay!...)

Is this realistic? There a endless other possibilities and there is no
reason why an attack to access exactly these directory paths is more
likely than the many other possibilities. Also why would attackers
choose this path in the first place? Putting a new ~/.i18n file in the
user's home directory seems to me to be more likely to succeed.

> I'm saying there is some impact.  I'm not aware of any meaningful way to
> measure it, but I don't think it's necessary: IMHO even making a "minor"
> impact is already bad idea.

I do not agree because the way you argue could be applied to anything
and there could always be the one imaginary exploit that will have a
payload that will only work because of $whatever and therefore make in
impact. For example from the other changes, what if there is a payload
that uses a feature of Golang 1.11 or a bug that is fixed in Binutils
2.31.

> Especially if I don't really see any convincing reason why this should
> be done.

I do not see any reason why a user would put something in ~/bin that
would mask something in /usr/bin except to actually mask the binary. It
is the same with other user configuration, anyone expects ~/.ssh/config
to override /etc/ssh/ssh_config instead of the other way round.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Q6NQNBDAXGDD5RX2RKX6HRUHJRXU6I4P/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Björn Persson

Nico Kadel-Garcia  wrote:
> On Sat, Jun 16, 2018 at 11:38 AM, Björn Persson  wrote:
> > Nico Kadel-Garcia wrote:  
> >> On Fri, Jun 15, 2018 at 12:55 PM, Till Maas  wrote:  
> >> > So the assumption is to have a super sophisticated browser exploit for 
> >> > which
> >> > an attacker most likely spent several days to find it and then the PATH
> >> > setting will make it so much harder that the exploit will not succeed? 
> >> > There
> >> > are a lot more real challenges that attackers have to face.  
> >>
> >> No "browser" sophistication is necessary. The replacement of default
> >> system utilities by anyone who write into that private but
> >> semi-concealed $HOME/.local/bin/  
> >
> > And how did the attacker acquire write access to $HOME/.local/bin/ in
> > the first place? Do you know of a way to do that so easily that
> > appending a line to one of the shell startup files seems sophisticated
> > in comparison?
> >
> > I don't much like the proposed change to PATH, but I'm getting *really*
> > sick of all the security by handwaving that's going on in this thread.
> > Could everybody please discuss *relevant* attack scenarios, instead of
> > scenarios that begin with the attacker already having so much access
> > that the value of PATH doesn't matter?
> >
> > Björn Persson  
> 
> There are many vectors for such attacks that a sensible, locked down,
> secure, monitored environment would not experience. Popular
> vulnerabilities include:
> 
> * Stolen passwords from penetrated hosts, used for SSH connections.

So the attacker already has full control of the user account, and can
read, write and execute whatever they want. I'll assume that the
scenario you're imagining is that the attacker tries to acquire further
privileges, as passphrases that aren't stored on disk is the only thing
the attacker doesn't already have.

Passphrases can be sniffed out in various ways, for example with a
wrapper program around su, or by attaching a debugger to a running
process, but all the methods I can think of are much more sophisticated
than appending a line to one of the shell startup files.

> Copying a file to $HOME/.local/bin requires far less scripting and
> awareness of existing contents than editing of .bashrc or .profile
> that reveals timestamp changes of the edited file,

cat .bashrc malicious >.bashrc.pwned
touch --reference .bashrc .bashrc.pwned
mv .bashrc.pwned .bashrc

Voila! Edited file with no awareness of existing contents and no
timestamp change. That is admittedly a little more scripting than
"scp malicious victim@target:.local/bin/su", but the actual malicious
program will be much longer in either case, so I don't see how that's a
significant hurdle.

> and differs from system defaults.

Hold on a second! Are you now imagining some kind of locked-down
environment where shell startup files are regularly compared to the
system defaults and an alarm is raised if they differ? If users aren't
allowed to edit their own startup files, then wouldn't those files be
root-owned and read-only?

> Since the contents of $HOME/.local/bin are not
> defined or definable, by its very nature, it's harder to audit.

So users in this hypothetical environment aren't allowed to edit their
own startup files, but are allowed to install programs in their home
directory. Is that right?

> * Fileshares of home directories. Many environments, especially
> university environments, use NFSv3 with quite general access. Welcome
> to write access to $HOME/ !!!

Well if they have made a decision to allow any user to write in any
other user's home directory, then they're obviously not worried about
users attacking each other. I would consider that unwise, but in that
context I don't see why they would care about security aspects of the
default PATH.

> And $HOME/.local/bin is notably less
> apparent than $HOME/bin, due to the default lack of "ls" reporting of
> contents of "." prefaced directories,

As .local and .bashrc are both hidden I see no difference in that
aspect.

> and of the difficulty of leaving
> security auditing to check .bashrc, .profile, etc.

If those files are difficult to audit, then they would seem like good
places to hide malicious code, and that code would be independent of
the default PATH.

Björn Persson

pgpj6fiRwO3J2.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/44JHJ5BA2N3L6NWS7I56PMZE32TK7ZVJ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Björn Persson

Ian Malone  wrote:
> 1. For example, a kiosk mode, where the home directory is wiped each
> login would be made less secure. The profile for the GUI is set at
> login, so writing .bash_profile has no effect on the GUI environment,
> but an attacker able to place files where the user has write
> permission could mask system binaries.

I agree with Zbigniew about this case: The protection fails as soon as
the user opens a terminal window.

> 2. The fact that a proof of concept cannot be provided is not a proof
> that a change you make is secure.

Nobody said it was.

And on the other hand: Somebody claiming that something is insecure, and
claiming to have a proof of concept without showing it, is not a proof
that there actually is a security problem.

> So this repeated insistence on providing a
> proof of concept before a security concern is taken seriously is
> fundamentally wrong, and I would be concerned to see it applied
> elsewhere in Fedora.

I asked for a proof of concept only because Tomasz Kłoczko claimed to
have one. I would otherwise be satisfied with a detailed description of
an attack scenario that can be analyzed to see whether it holds water.
I jumped into this debate because I couldn't stomach all the "It's
insecure because handwaving." and "It's insecure because I've said so
several times.".

Björn Persson

pgpJCfL1Me0sp.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JO2GINHLQBTK5OBXLOFGTEH2T36BHGMR/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Matthew Miller

On Mon, Jun 18, 2018 at 04:48:43PM +0200, Vít Ondruch wrote:
> > https://fedoraproject.org/wiki/Fedora_Kiosk
> It does not look to be maintained ...

It seems to have  never been completed. Note the category "Spins in
Development", as well as this bit:

  The most recent blog post by the developer was Introducing the Fedora
  Kiosk Spin, April 30th 2010, at which stage it was "under development
  (as is F13)." 

In general, the wiki is not a great source of truth.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TVLI6UGTQ3OSMVDL4TDO2TC32TPP3JX7/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Vít Ondruch

Dne 18.6.2018 v 16:30 Tomasz Kłoczko napsal(a):
> On Mon, 18 Jun 2018 at 14:58, Vít Ondruch  wrote:
> [..]
>> Forgive my ignorance, but where is the option to install Fedora in Kiosk
>> mode? I am asking, because I am not aware about any option like this,
>> hence this needs IMO some configuration and if you configure the
>> computer to run in Kiosk mode, then you can certainly modify the PATH to
>> improve security of such setup.
> https://fedoraproject.org/wiki/Fedora_Kiosk
> And no .. you cannot at the moment do to much about $PATH because
> modifications about this env variable are spread across multiple
> packages.
> In most of the cases this cannot be changed without patching source
> code and recompile exact packages.
>
> kloczek

It does not look to be maintained ...

V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MCJKGWASLBBL3N55GOCI6IP56AZH4P3S/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Tomasz Kłoczko

On Mon, 18 Jun 2018 at 14:58, Vít Ondruch  wrote:
[..]
> Forgive my ignorance, but where is the option to install Fedora in Kiosk
> mode? I am asking, because I am not aware about any option like this,
> hence this needs IMO some configuration and if you configure the
> computer to run in Kiosk mode, then you can certainly modify the PATH to
> improve security of such setup.

https://fedoraproject.org/wiki/Fedora_Kiosk
And no .. you cannot at the moment do to much about $PATH because
modifications about this env variable are spread across multiple
packages.
In most of the cases this cannot be changed without patching source
code and recompile exact packages.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RLG6KHAVXOJZSVAEWM5O2Y7PXYOM7OZA/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Vít Ondruch



Dne 18.6.2018 v 00:13 Ian Malone napsal(a):
> On 16 June 2018 at 13:50, Björn Persson  wrote:
>> Tomasz Kłoczko wrote:
>>> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
>>> [..]
 Don't forget that if your proof of concept can be modified to either
 overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
>>> before ~/.bashrc is executed many other scripts  executions
>>> already is finished
>> This is true and completely irrelevant.
>>
>>> Whatever you want to do over you account session or profile scripts it
>>> is already _to late_.
>>> Is that clear now?
>> No it's not clear. I have no idea why you're rambling about the order
>> in which Bash executes its startup files. The order doesn't matter,
>> especially since the hypothetical attacker is supposedly unable to
>> modify those files.
>>
>> You claimed to have a proof of concept that would demonstrate how some
>> security hole can be exploited if and only if ~/.local/bin is listed
>> before /usr/bin in PATH. I asked you to post your proof of concept. You
>> didn't. I will therefore conclude that you don't actually have one.
>>
>
> Well, two things:
>
> 1. For example, a kiosk mode, where the home directory is wiped each
> login would be made less secure.

Forgive my ignorance, but where is the option to install Fedora in Kiosk
mode? I am asking, because I am not aware about any option like this,
hence this needs IMO some configuration and if you configure the
computer to run in Kiosk mode, then you can certainly modify the PATH to
improve security of such setup.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J33IAEELIZPPCGKZC7BMNKARVJOFWEQ3/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Tomasz Kłoczko

On Mon, 18 Jun 2018 at 12:18, Ian Malone  wrote:
[..]
> > Even if .bash_profile is not always read, .bashrc is read every time
> > a shell is started (OK, not "every time", but often enough). So for
> > example if I open a new tab in the terminal, or run some scripting plugin
> > from an editor, etc, the effect is the same as overwriting .bash_profile.
> >
>
> But these assume you are only attacking the shell. The system path is
> used to resolve commands started from the gui too, independent of
> bash.

In context of so called of "Nobody expects The Spanish Inquisition"
effect (understood as OOTB distro resources using executables and/or
data and/or configuration files which are not part of the regular
distribution) it is not only about targeting bash.
Many applications reads own env variables and passes $PATH down to
executed processes (this depends on variant exec() syscall used to
execute other processes). If application A will be executing script
interpreter which result will be used byt this A application it may
mean targeting exactly such application.

For example in case of have /usr/local/bin/id you can observe that
gnome-terminal started from command line and GUI menu are altere.
In other words this effect is literally spreads as well across most of
the /usr/share/application/*desktop files (just grep those files for
^Exec=).
Using in Exec= only binary name instead full path would be nothing bad
.. however this mixed with currently used $PATH really changes
everything!

And here is kind od "binary effect" of the "Nobody expects The Spanish
Inquisition" effect.
There are some number of properties of the current packages which
separately *does not increases risk*.
However, mixed with other packages properties on interacting with
those resources they are forming context with *non-zero risk*.
And it is one of those reasons why it was so easy to see those consequences :)

Simple  .. most of the people do not expect that 0+0 suddenly will be
>=0. Isn't it?
Truth is that here works a bit different type of algebra.
Whoever knows mathematics above some level knows that it is nothing
unusual to have such outcome.
By define "+" operation as a+b+ more times will be used "+"
operation than greated non-zero value will be even when a=b=0.

Another small exempla of this whole effect could be provided by
executing most of the python scripts.
In output of the "strace -e trace=file dnf" you will be able to find
fragments like:

stat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=43016, ...}) = 0
stat("/usr/bin/dnf/__init__.cpython-36m-x86_64-linux-gnu.so",
0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.abi3.so", 0x7ffee21f8970) = -1 ENOTDIR
(Not a directory)
stat("/usr/bin/dnf/__init__.so", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.py", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf/__init__.pyc", 0x7ffee21f8970) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/dnf", {st_mode=S_IFREG|0755, st_size=1942, ...}) = 0

stat("/usr/bin", {st_mode=S_IFDIR|0555, st_size=43016, ...}) = 0
stat("/usr/bin/locale/__init__.cpython-36m-x86_64-linux-gnu.so",
0x7ffee21f40f0) = -1 ENOTDIR (Not a directory)
stat("/usr/bin/locale/__init__.abi3.so", 0x7ffee21f40f0) = -1 ENOTDIR
(Not a directory)
stat("/usr/bin/locale/__init__.so", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale/__init__.py", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale/__init__.pyc", 0x7ffee21f40f0) = -1 ENOTDIR (Not
a directory)
stat("/usr/bin/locale", {st_mode=S_IFREG|0755, st_size=63888, ...}) = 0

or lines like:

openat(AT_FDCWD, "/usr/bin/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such
file or directory)
openat(AT_FDCWD, "/usr/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat("/usr/bin/pyvenv.cfg", 0x7ffebc328a60) = -1 ENOENT (No such file
or directory)
stat("/usr/pyvenv.cfg", 0x7ffebc328a60) = -1 ENOENT (No such file or directory)

None of those paths are used in the dnf own code ..

If you know that exact application is using exact location to find
executables, scripting languages extensions/modules or configuration
files BEFORE checking well known paths in which other packages are
installing those types of resources you can use those locations to
alter how exact application is working without touching to many bells.

I've already mention about risk of altering of what for example
gcc/g++ is producing on Fedora build systems.
You can drop in /usr/local/bin most of the executables used during
building packages processes and you will be not be able to see
anything new/obvious looking on the build logs. It will be especially
easy in case of all packages build frameworks which are suppressing
verbosity level where are only logged details in a way like:
"CC: file.c"
"LD: prog"
This is why I've mention few times on this list about take care of
enable MAXIMUM possible verbosity level in build logs on Fedora build
systems.

Despite

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Ian Malone

On 18 June 2018 at 11:27, Zbigniew Jędrzejewski-Szmek  wrote:
> On Sun, Jun 17, 2018 at 11:13:39PM +0100, Ian Malone wrote:
>> On 16 June 2018 at 13:50, Björn Persson  wrote:
>> > Tomasz Kłoczko wrote:
>> >> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
>> >> [..]
>> >> > Don't forget that if your proof of concept can be modified to either
>> >> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
>> >>
>> >> before ~/.bashrc is executed many other scripts  executions
>> >> already is finished
>> >
>> > This is true and completely irrelevant.
>> >
>> >> Whatever you want to do over you account session or profile scripts it
>> >> is already _to late_.
>> >> Is that clear now?
>> >
>> > No it's not clear. I have no idea why you're rambling about the order
>> > in which Bash executes its startup files. The order doesn't matter,
>> > especially since the hypothetical attacker is supposedly unable to
>> > modify those files.
>> >
>> > You claimed to have a proof of concept that would demonstrate how some
>> > security hole can be exploited if and only if ~/.local/bin is listed
>> > before /usr/bin in PATH. I asked you to post your proof of concept. You
>> > didn't. I will therefore conclude that you don't actually have one.
>> >
>>
>>
>> Well, two things:
>>
>> 1. For example, a kiosk mode, where the home directory is wiped each
>> login would be made less secure. The profile for the GUI is set at
>> login, so writing .bash_profile has no effect on the GUI environment,
>> but an attacker able to place files where the user has write
>> permission could mask system binaries.
>
> Even if .bash_profile is not always read, .bashrc is read every time
> a shell is started (OK, not "every time", but often enough). So for
> example if I open a new tab in the terminal, or run some scripting plugin
> from an editor, etc, the effect is the same as overwriting .bash_profile.
>

But these assume you are only attacking the shell. The system path is
used to resolve commands started from the gui too, independent of
bash.

> But more generally, if one uses a public kiosk that somebody else had
> logged into first, for *any* purpose requiring security, that is a
> grave mistake already. How would one even know that the gui they are
> accessing hasn't been substituted wholesale?
>

This is a misdirection. We can still worry about an attack on a user
logging into a clean profile (the case I was discussing), or from the
point of view of the kiosk administrator concerned with ensuring the
security of their users, the system itself and the network it's
attached to. To put it another way, you probably use a proprietary CPU
in your computer, how do you know it's not compromised? Why do we
worry at all about security if you can't guarantee that?

>> But a more major worry for me here, the reason I'm bothering to reply
>> to a thread about setting paths (though to be honest, someone who
>> doesn't understand how to do that may not have much business
>> installing unpackaged software, particularly when the examples are
>> developer tools):
>>
>> 2. The fact that a proof of concept cannot be provided is not a proof
>> that a change you make is secure. Take Spectre; that vulnerability has
>> been around for decades with no public proof of concept, or even
>> knowledge there was a vulnerability, yet it can be exploited from
>> Javascript in a browser. So this repeated insistence on providing a
>> proof of concept before a security concern is taken seriously is
>> fundamentally wrong, and I would be concerned to see it applied
>> elsewhere in Fedora.
>
> In this case we understand what the change in behaviour means, we just
> seem to disagree on how significant this is. We even know how any such
> exploit would look. The calls to provide a POC have the intent to take
> any such POC and tweak it to modify .bash_profile/.bashrc/.i18n instead,
> and thus turn the discussion around by showing that $PATH order is
> irrelevant to the attack.
>

Fundamentally flawed approach, since you are assuming you know the
constraints an attacker is working under, here you assume that they
are able to freely write to all locations the user can access. This
may not always be the case. An attacker's first job is to leverage a
weakness to gain that control. As I mentioned what worries me most is
this attitude that you must be smarter than the attacker and that you
do not need to think defensively because of that.


-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OKVKAN4NTSNP5WAWGFSEFLUWUABDU47H/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Zbigniew Jędrzejewski-Szmek

On Sun, Jun 17, 2018 at 11:13:39PM +0100, Ian Malone wrote:
> On 16 June 2018 at 13:50, Björn Persson  wrote:
> > Tomasz Kłoczko wrote:
> >> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
> >> [..]
> >> > Don't forget that if your proof of concept can be modified to either
> >> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
> >>
> >> before ~/.bashrc is executed many other scripts  executions
> >> already is finished
> >
> > This is true and completely irrelevant.
> >
> >> Whatever you want to do over you account session or profile scripts it
> >> is already _to late_.
> >> Is that clear now?
> >
> > No it's not clear. I have no idea why you're rambling about the order
> > in which Bash executes its startup files. The order doesn't matter,
> > especially since the hypothetical attacker is supposedly unable to
> > modify those files.
> >
> > You claimed to have a proof of concept that would demonstrate how some
> > security hole can be exploited if and only if ~/.local/bin is listed
> > before /usr/bin in PATH. I asked you to post your proof of concept. You
> > didn't. I will therefore conclude that you don't actually have one.
> >
> 
> 
> Well, two things:
> 
> 1. For example, a kiosk mode, where the home directory is wiped each
> login would be made less secure. The profile for the GUI is set at
> login, so writing .bash_profile has no effect on the GUI environment,
> but an attacker able to place files where the user has write
> permission could mask system binaries.

Even if .bash_profile is not always read, .bashrc is read every time
a shell is started (OK, not "every time", but often enough). So for
example if I open a new tab in the terminal, or run some scripting plugin
from an editor, etc, the effect is the same as overwriting .bash_profile.

But more generally, if one uses a public kiosk that somebody else had
logged into first, for *any* purpose requiring security, that is a
grave mistake already. How would one even know that the gui they are
accessing hasn't been substituted wholesale?

> But a more major worry for me here, the reason I'm bothering to reply
> to a thread about setting paths (though to be honest, someone who
> doesn't understand how to do that may not have much business
> installing unpackaged software, particularly when the examples are
> developer tools):
> 
> 2. The fact that a proof of concept cannot be provided is not a proof
> that a change you make is secure. Take Spectre; that vulnerability has
> been around for decades with no public proof of concept, or even
> knowledge there was a vulnerability, yet it can be exploited from
> Javascript in a browser. So this repeated insistence on providing a
> proof of concept before a security concern is taken seriously is
> fundamentally wrong, and I would be concerned to see it applied
> elsewhere in Fedora.

In this case we understand what the change in behaviour means, we just
seem to disagree on how significant this is. We even know how any such
exploit would look. The calls to provide a POC have the intent to take
any such POC and tweak it to modify .bash_profile/.bashrc/.i18n instead,
and thus turn the discussion around by showing that $PATH order is
irrelevant to the attack.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6F643BHFN4DN5YD2XHVK5I5B7QC4I3KA/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-18 Thread Ian Malone

On 18 June 2018 at 00:49, Tomasz Kłoczko  wrote:
> On Sun, 17 Jun 2018 at 23:23, Ian Malone  wrote:
> [..]
>> Well, two things:
>>
>> 1. For example, a kiosk mode, where the home directory is wiped each
>> login would be made less secure. The profile for the GUI is set at
>> login, so writing .bash_profile has no effect on the GUI environment,
>> but an attacker able to place files where the user has write
>> permission could mask system binaries.
> [..]
>
> Do you want to say that Linux on the kiosk type system requires
> /usr/local based paths on the front of the $PATH?
> If not .. sorry to say this but somehow you lost context of the
> discussion is, and you just started adding some random comments.
> Please don't this.
>

No I did not, please re-read original email and the one I was replying to.


-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JOQLGL3PT4AAG3JVVMAWLBFJOI45U4RX/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-17 Thread Tomasz Kłoczko

On Sun, 17 Jun 2018 at 23:23, Ian Malone  wrote:
[..]
> Well, two things:
>
> 1. For example, a kiosk mode, where the home directory is wiped each
> login would be made less secure. The profile for the GUI is set at
> login, so writing .bash_profile has no effect on the GUI environment,
> but an attacker able to place files where the user has write
> permission could mask system binaries.
[..]

Do you want to say that Linux on the kiosk type system requires
/usr/local based paths on the front of the $PATH?
If not .. sorry to say this but somehow you lost context of the
discussion is, and you just started adding some random comments.
Please don't this.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6TJTTVOHWBOZ6NM6LPBUAC3LIEL5AOEB/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-17 Thread Tomasz Kłoczko

On Sun, 17 Jun 2018 at 20:03, Matthew Miller  wrote:
[..]
> > Prioritizing security issues is only possible in context of the RISK.
>
> That's only part of the equation. Practical security has to fairly
> assess and balance risk _against requirements_.

Please back to the equation and requirements.
Do you know anything what requires in the distribution to have
/usr/local based paths on the front of the $PATH?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MIHYN7UWDWBQVBJ2BHJS7H4BZAOWZZHE/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-17 Thread Ian Malone

On 16 June 2018 at 13:50, Björn Persson  wrote:
> Tomasz Kłoczko wrote:
>> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
>> [..]
>> > Don't forget that if your proof of concept can be modified to either
>> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
>>
>> before ~/.bashrc is executed many other scripts  executions
>> already is finished
>
> This is true and completely irrelevant.
>
>> Whatever you want to do over you account session or profile scripts it
>> is already _to late_.
>> Is that clear now?
>
> No it's not clear. I have no idea why you're rambling about the order
> in which Bash executes its startup files. The order doesn't matter,
> especially since the hypothetical attacker is supposedly unable to
> modify those files.
>
> You claimed to have a proof of concept that would demonstrate how some
> security hole can be exploited if and only if ~/.local/bin is listed
> before /usr/bin in PATH. I asked you to post your proof of concept. You
> didn't. I will therefore conclude that you don't actually have one.
>

Well, two things:

1. For example, a kiosk mode, where the home directory is wiped each
login would be made less secure. The profile for the GUI is set at
login, so writing .bash_profile has no effect on the GUI environment,
but an attacker able to place files where the user has write
permission could mask system binaries.

But a more major worry for me here, the reason I'm bothering to reply
to a thread about setting paths (though to be honest, someone who
doesn't understand how to do that may not have much business
installing unpackaged software, particularly when the examples are
developer tools):

2. The fact that a proof of concept cannot be provided is not a proof
that a change you make is secure. Take Spectre; that vulnerability has
been around for decades with no public proof of concept, or even
knowledge there was a vulnerability, yet it can be exploited from
Javascript in a browser. So this repeated insistence on providing a
proof of concept before a security concern is taken seriously is
fundamentally wrong, and I would be concerned to see it applied
elsewhere in Fedora.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J7YVS2NVEPDF5TEZ2EFGFKI6TB42F3HA/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-17 Thread Matthew Miller

On Sun, Jun 17, 2018 at 10:03:30AM +0100, Tomasz Kłoczko wrote:
> Przemek .. what you mean "this is NOT a serious security issue"?
> Is it possible to be not serious pregnant?
> Something IS security issue or NOT at all. Isn't it?
> There are ONLY TWO possible states in context of security, and there
> is nothing in the middle.

That's demonstrably not true. As the very old saying goes, the safest
computer is disconnected from the Internet, and unplugged, and put in a
box, and that box put in a lead case, and that case taken out to the
middle of the ocean and dropped overboard.

It's not helpful to think about security as an absolute.

> Prioritizing security issues is only possible in context of the RISK.

That's only part of the equation. Practical security has to fairly
assess and balance risk _against requirements_.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NUFGAQZFUBJJ4ZISRTFZIR4H7YT3QDW6/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-17 Thread Björn Persson

Tomasz Kłoczko wrote:
> Just please add /usr/local/bin/id text file with content:
> 
> #!/bin/sh
> echo "No one expects The Spanish Inquisition!"
> exec /usr/bin/id $*

I can't:

bash: /usr/local/bin/id: Permission denied

Björn Persson


pgpmM0qMeoYoJ.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/54LBT27YTTGHH6SQJN3JLCUVNMMGEXOE/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-17 Thread Tomasz Kłoczko

On Sun, 17 Jun 2018 at 03:18, Przemek Klosowski
 wrote:
[..]
> I have mixed feelings about that. On one hand,  I agree that this is NOT
> a serious security issue (it's essentially a local compromise requiring
> an existing local compromise), so if someone claims it'll make their
> life easier, I want to say 'just do it'.

Przemek .. what you mean "this is NOT a serious security issue"?
Is it possible to be not serious pregnant?
Something IS security issue or NOT at all. Isn't it?
There are ONLY TWO possible states in context of security, and there
is nothing in the middle.

Do you know that on the beginning of the U*nix history buffer overflow
bugs or sniffing passwords in the network traffic have been named as
"not a serious security issue" as well for quite long time?

Prioritizing security issues is only possible in context of the RISK.
If today every BO or tmp directory content issue is wiped out
instantly on spot using raw fire I can tell you that RISK of
exploiting $PATH issues is far more greater than those tmp ones.
If only those /tmp issues are treated so seriously why $PATH issue
isn't something at least so dangerous like like those well known?
Because it is something neweis?

Because in case of /tmp issues there are still SIGNIFICANT number of
people remembering multi million loses by those issue and in case of
$PATH issues still no one can point on such cases discussed publicly.
In other words naming those issues as "NOT a serious security issue"
it is nothing more than oxymoron (phare with internal contradiction).

Problem with $PATH is really deep.

In Fedora like in all Linux distributions there is no clear
demarcation line between what should provide distribution for pure end
user who is going to use ONLY distribution resources and someone who
is more or less developer who is quite often working on the future
versions of some software which may even land sooner or later in the
Linux distribution.
What was in the past only temporary power user/developer kind of JFDI
solution which should not have any (especially permanent) impact those
from first group of the users started spreading .. and now IT
AFFECTS!!!
Many people without technical knowledge are probably assuming that
because using /usr/local was present OOTB so long, it cannot be so
dangerous (because if it were the case a long time ago, it would be
removed). Some people say that sometimes darkener place on the street
is just right under the street lamp and here is something very
similar.
This case is some diabolic mixture bad developers
behaviour/methodologies, "death by thousands of cuts" effect and even
crowd psychology.

Here is additional fact: there are few Unixes around which have no
/usr/local/{bin,sbin} paths in the OOTB $PATH and those Unixes are
using the same versions of the python or desktop software like on
Linuxes.

Today all this legacy or old development baggage which cause all this
is IMO today so absurd and at the same time is hard to understand by
even avg skilled Unix engineer.
Some time ago trying to explain the impact of this issue I was so
frustrated that I've thought that I must look during all those
explanations like one of those "purpurate cardinals" from classic
Monty Python sketch "No one expects The Spanish Inquisition!".
https://youtu.be/oJZ2m6_T1wc

So after this I've started even calling this "new" class of security issues as:

"'No one expects The Spanish Inquisition' effect"

Generally, it is not only about $PATH, using env but as well checking
and using configuration files locations BEFORE using those package
binaries suppose to use OOTB configuration files.
Just try to have closer look on what prints below oneliner:

# strings /usr/{,s}bin/*| grep "^/" | egrep "bin|cfg|conf"|sort|uniq

Than you may try to extend this oneliner a bit to:

# strings /usr/{,s}bin/*| grep "^/" | egrep "bin|cfg|conf"|sort|uniq |
awk '{print $1}' | xargs rpm -qf

and right after this you may ask yourself: why so many are paths
hardcoded in so many files and are not owned by any package?
Someone with bad intentions will probably ask: how can I use checking
those cfg path or executing something from those paths to plug-in
something into **not changed OS distribution resources**?

Those outputs only encircles few possible swampy areas. I can tell
that I've already found more than few cases which really can be
exploited.
So far trying to investigate the impact of this (idiotic) "No one
expects The Spanish Inquisition effect" I found that it affects not
only all Linuxes or other U*nixes like Solaris, *BSD and other
flavours but in some rare cases even Windows.
My fiend checking Windows found for example that some Windows packages
installers are altering Windows system search path adding on the front
system env variable own base path and/or some base paths which this
software is not even using (and that is even more bizarre/odd).
This issue is so widely spread because all those OSesses are sharing
many pieces of source code.

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-16 Thread Kyle Marek

On 06/16/2018 01:17 PM, Nico Kadel-Garcia wrote:
> On Sat, Jun 16, 2018 at 11:38 AM, Björn Persson  wrote:
>> Nico Kadel-Garcia wrote:
>>> On Fri, Jun 15, 2018 at 12:55 PM, Till Maas  wrote:
 So the assumption is to have a super sophisticated browser exploit for 
 which
 an attacker most likely spent several days to find it and then the PATH
 setting will make it so much harder that the exploit will not succeed? 
 There
 are a lot more real challenges that attackers have to face.
>>> No "browser" sophistication is necessary. The replacement of default
>>> system utilities by anyone who write into that private but
>>> semi-concealed $HOME/.local/bin/
>> And how did the attacker acquire write access to $HOME/.local/bin/ in
>> the first place? Do you know of a way to do that so easily that
>> appending a line to one of the shell startup files seems sophisticated
>> in comparison?
>>
>> I don't much like the proposed change to PATH, but I'm getting *really*
>> sick of all the security by handwaving that's going on in this thread.
>> Could everybody please discuss *relevant* attack scenarios, instead of
>> scenarios that begin with the attacker already having so much access
>> that the value of PATH doesn't matter?
>>
>> Björn Persson
> There are many vectors for such attacks that a sensible, locked down,
> secure, monitored environment would not experience. Popular
> vulnerabilities include:
>
> * Stolen passwords from penetrated hosts, used for SSH connections.
> Copying a file to $HOME/.local/bin requires far less scripting and
> awareness of existing contents than editing of .bashrc or .profile
> that reveals timestamp changes of the edited file, and differs from
> system defaults. Since the contents of $HOME/.local/bin are not
> defined or definable, by its very nature, it's harder to audit.
> * Fileshares of home directories. Many environments, especially
> university environments, use NFSv3 with quite general access. Welcome
> to write access to $HOME/ !!!  And $HOME/.local/bin is notably less
> apparent than $HOME/bin, due to the default lack of "ls" reporting of
> contents of "." prefaced directories, and of the difficulty of leaving
> security auditing to check .bashrc, .profile, etc.
>
> Does that give you enough examples of unnecessarily vulnerable vectors
> opened by default by the casual assumption that "ohh, they could get
> in another way, so I don't have to worry about the hole *I* am
> suggesting opening up!!!"

I know there was a statement against "if they can do X then they can do
Y" statements previously. However: I don't think that prioritizing
user-controlled path directories is giving a hypothetical attacker an
advantage since they can even re-implement this with the equivalent of:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc


I think it is appropriate to say that this is no more inappropriate than
user-controlled files (like .bashrc or .profile) being executed during
session startup or shell startup in the first place.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PW5EW7SRZ4CNH442LRMDC52YEF46U5ET/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-16 Thread Nico Kadel-Garcia

On Sat, Jun 16, 2018 at 11:38 AM, Björn Persson  wrote:
> Nico Kadel-Garcia wrote:
>> On Fri, Jun 15, 2018 at 12:55 PM, Till Maas  wrote:
>> > So the assumption is to have a super sophisticated browser exploit for 
>> > which
>> > an attacker most likely spent several days to find it and then the PATH
>> > setting will make it so much harder that the exploit will not succeed? 
>> > There
>> > are a lot more real challenges that attackers have to face.
>>
>> No "browser" sophistication is necessary. The replacement of default
>> system utilities by anyone who write into that private but
>> semi-concealed $HOME/.local/bin/
>
> And how did the attacker acquire write access to $HOME/.local/bin/ in
> the first place? Do you know of a way to do that so easily that
> appending a line to one of the shell startup files seems sophisticated
> in comparison?
>
> I don't much like the proposed change to PATH, but I'm getting *really*
> sick of all the security by handwaving that's going on in this thread.
> Could everybody please discuss *relevant* attack scenarios, instead of
> scenarios that begin with the attacker already having so much access
> that the value of PATH doesn't matter?
>
> Björn Persson

There are many vectors for such attacks that a sensible, locked down,
secure, monitored environment would not experience. Popular
vulnerabilities include:

* Stolen passwords from penetrated hosts, used for SSH connections.
Copying a file to $HOME/.local/bin requires far less scripting and
awareness of existing contents than editing of .bashrc or .profile
that reveals timestamp changes of the edited file, and differs from
system defaults. Since the contents of $HOME/.local/bin are not
defined or definable, by its very nature, it's harder to audit.
* Fileshares of home directories. Many environments, especially
university environments, use NFSv3 with quite general access. Welcome
to write access to $HOME/ !!!  And $HOME/.local/bin is notably less
apparent than $HOME/bin, due to the default lack of "ls" reporting of
contents of "." prefaced directories, and of the difficulty of leaving
security auditing to check .bashrc, .profile, etc.

Does that give you enough examples of unnecessarily vulnerable vectors
opened by default by the casual assumption that "ohh, they could get
in another way, so I don't have to worry about the hole *I* am
suggesting opening up!!!"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQZTAIOMT5Z357HV2EHRNIN7G7YT6TTQ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-16 Thread Björn Persson

Nico Kadel-Garcia wrote:
> On Fri, Jun 15, 2018 at 12:55 PM, Till Maas  wrote:
> > So the assumption is to have a super sophisticated browser exploit for which
> > an attacker most likely spent several days to find it and then the PATH
> > setting will make it so much harder that the exploit will not succeed? There
> > are a lot more real challenges that attackers have to face.  
> 
> No "browser" sophistication is necessary. The replacement of default
> system utilities by anyone who write into that private but
> semi-concealed $HOME/.local/bin/

And how did the attacker acquire write access to $HOME/.local/bin/ in
the first place? Do you know of a way to do that so easily that
appending a line to one of the shell startup files seems sophisticated
in comparison?

I don't much like the proposed change to PATH, but I'm getting *really*
sick of all the security by handwaving that's going on in this thread.
Could everybody please discuss *relevant* attack scenarios, instead of
scenarios that begin with the attacker already having so much access
that the value of PATH doesn't matter?

Björn Persson

pgpbnAoFRSMKt.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RONATBV5Z2E2AUGKQ4BFJIETMIKZZ6M3/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-16 Thread Nico Kadel-Garcia

On Fri, Jun 15, 2018 at 12:55 PM, Till Maas  wrote:

> So the assumption is to have a super sophisticated browser exploit for which
> an attacker most likely spent several days to find it and then the PATH
> setting will make it so much harder that the exploit will not succeed? There
> are a lot more real challenges that attackers have to face.

No "browser" sophistication is necessary. The replacement of default
system utilities by anyone who write into that private but
semi-concealed $HOME/.local/bin/, which is notably less apparent than
$HOME/bin, can introduce a trojaned binary that can even erase itself
after a single abusive attempt against the user. This includes all the
system binaries in /usr/bin and /bin/, since they are now *ahead* of
the default $PATH.

>> If I was writing malware, I would be much happier with just being able
>> to drop a file in ~/bin or ~/.local/bin than doing the research on where
>> PATH is actually being set, and then getting the `sed` right, and all
>> that **without** being immediately discovered (eg. because I broke the
>> syntax or caused error).
>
>
> If the attacker can already call sed, then they do not need to drop a
> binary. Also they do not need to research where PATH is actually set.

To be less apparent about their work, yes, they do. It's much easier
to climb in the open back door than bother picking a lock, even if you
know how to pick locks or the lock isn't very good.

> The initial theory in this thread was that it is a significant security
> risk. And all the arguments for this are either "it's obvious" or are based
> on arbitrarily constructed scenarios. If you are saying it just makes a
> minor impact, then we do not need to discuss further because this is good
> enough for me.

No, you just keep claiming to have discredited them. I think you're
seriously outvoted on this one, especially since the "put
$HOME/local/.bin" first by default is *exactly* what you, personally,
can be done on a case by case basis if it's *really* needed by an an
individual. Since "manipulating .bashrc is so trivial", let the people
who need a non-standard PATH set up their own and take their own
risks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2VQSL3446RGUEXJJWM6YW2LZ7KK5ITOZ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-16 Thread Björn Persson

Tomasz Kłoczko wrote:
> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
> [..]
> > Don't forget that if your proof of concept can be modified to either
> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.  
> 
> before ~/.bashrc is executed many other scripts  executions
> already is finished

This is true and completely irrelevant.

> Whatever you want to do over you account session or profile scripts it
> is already _to late_.
> Is that clear now?

No it's not clear. I have no idea why you're rambling about the order
in which Bash executes its startup files. The order doesn't matter,
especially since the hypothetical attacker is supposedly unable to
modify those files.

You claimed to have a proof of concept that would demonstrate how some
security hole can be exploited if and only if ~/.local/bin is listed
before /usr/bin in PATH. I asked you to post your proof of concept. You
didn't. I will therefore conclude that you don't actually have one.

Björn Persson

pgp6KC_oaj2KQ.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W7FD5RX2WWHIKRGM2LS5Q6N7X24DBTAQ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-16 Thread Tomasz Kłoczko

On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
[..]
> Don't forget that if your proof of concept can be modified to either
> overwrite or append to ~/.bashrc, then it's irrelevant to this debate.

Is it really so hard to execute "strace -trace=openat,stat bash -l" to
spot that before ~/.bashrc is executed many other scripts  executions
already is finished or if someone  don't know how to use strace just
read bash(1) man page?

Part of such example strace output:

openat(AT_FDCWD, "/etc/profile", O_RDONLY) = 3
[..]
openat(AT_FDCWD, "/etc/bashrc", O_RDONLY) = 3
openat(AT_FDCWD, "/home/tkloczko/.bash_profile", O_RDONLY) = 3
stat("/home/tkloczko/.bashrc", {st_mode=S_IFREG|0644, st_size=192, ...}) = 0

Quote from bash(1):
"When bash is invoked as an interactive login shell, or as a
non-interactive shell with the --login option, _it first reads and
executes commands from the file /etc/profile_,  if  that file exists.
After reading that file, it looks for ~/.bash_profile, ~/.bash_login,
and ~/.profile, in that order, and reads and executes commands from
the first one that exists and is readable.  The --noprofile option may
be used when the shell is started to inhibit this behavior."

Whatever you want to do over you account session or profile scripts it
is already _to late_.
Is that clear now?

If you have no time to at least try-by-experiment to disprove what
already have been written in this thread just please stop posting
commentS because you giving clear signal that you are not even trying
to understand the subject.

Is it really so hard to use strace command to trace what really is
done during shell session initialization with current fedora default
settings?
If doing such test is out of all Fedora Committees members TECHNICAL
skills discussing this subject here is really pointless.

My understanding is that Fedora already identified REAL risk of using
env command because currently used Fedora rpm packages build framework
automatically removed using env in all scripts before generate
packages. In other words level of this risk is KNOWN and enough well
understood by engineers taking care of security aspects of Fedora
packages.
So here is the "news" if it is still not obvious: risk factor of using
env is MAINLY because current $PATH.

And one more time: can someone please point on technical justification
of putting /usr/local based pathsh on front of the $PATH?
I'm 100% sure that Fedora Comeeties members (current or past) should
know where such justification is documented (?)
If there is no such justification according to lex parsimoniae (or
better known as Ockham Razor) this should cause instant action remove
use those paths in OOTB settings.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4QHXI2I25RJ46KO4LERWUQBW6HI52J6V/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-15 Thread Alec Leamas



On 15/06/18 19:52, Przemek Klosowski wrote:

> I have mixed feelings about that. On one hand,  I agree that this is NOT
> a serious security issue (it's essentially a local compromise requiring
> an existing local compromise), so if someone claims it'll make their
> life easier, I want to say 'just do it'.
> 
> On the other hand, I am uneasy about the whole thing: the PATH ordering
> only matters for system-provided software, so we're essentially either
> acknowledging that we can't keep up with a decently updated
> distribution, or accommodating a very small group that needs cutting
> edge stuff that is not relevant to the vast majority of users.

+1

This is now a very long thread dominated by the security questions like
"what if?". Nothing bad in that, but we need to keep some focus also on
the usecases to be able to make the inevitable trade-off between
usability and security.

The usecase represented by npm et. al. is important. To have the
platform so secure that these environments doesn't work out of the box
is probably to shoot ourselves in our feet.


Cheers!

..alec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VWGIFKY7E3N4KCAGGH4E5RTXC5KMFX7W/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-15 Thread Przemek Klosowski


On 06/15/2018 07:30 AM, Tomasz Kłoczko wrote:

Nevertheless still no one answered on very simple question. So I'll repeat it:

Why Fedora_must_  offer OOTB ~/.local/bin, /usr/local{s,}bin paths on
the front of the $PATH in OOTB settings?


The churn in some software (javascript, python, ...) is such that the 
system-provided executables do not work and must be overridden from 
private PATH locations. This is acute enough that users of npm, conda 
etc. demand the front-of-PATH locations, to make sure they can override 
the system-provided executables.


I have mixed feelings about that. On one hand,  I agree that this is NOT 
a serious security issue (it's essentially a local compromise requiring 
an existing local compromise), so if someone claims it'll make their 
life easier, I want to say 'just do it'.


On the other hand, I am uneasy about the whole thing: the PATH ordering 
only matters for system-provided software, so we're essentially either 
acknowledging that we can't keep up with a decently updated 
distribution, or accommodating a very small group that needs cutting 
edge stuff that is not relevant to the vast majority of users.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MANVBPJOIPUN6K4PLHV7JMA4SYB3KCKJ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-15 Thread Till Maas

Hi,

Am 15.06.2018 um 00:50 schrieb Alois Mahdal:

On 06/14/2018 11:37 PM, Till Maas wrote:

Hi,

On Thu, Jun 14, 2018 at 04:19:27PM +0200, Alois Mahdal wrote:

On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote:
What about attack success rate?
But if the attacker is some browser exploit able to take a shot at many
users (not knowing what their OS, let alone default $PATH is), then I

The browser knows the OS, see the User-Agent header, for example:
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Name

Also the PATH would be in the browser environment, so easy to access,
too. However, if this information is not available to the attacker, why
would they know the value of $HOME/bin or $HOME/.local/bin? They would
have to know the user's username for this. IMHO these are not convincing
assumptions.

Those are not assumptions. It would be incorrect to assume that.

I do not follow here because these assumptions are made by you in your
argumentation as far as I can see.

What I'm trying to say is that with these kinds of attack (like viruses,
or exploits on massively accessed page), there is inevitably going to be
some sort of economic decision on side of author affecting how "smart"
they want the code to be.

Thus, every little step you're making towards "easier" translates to
dumber exploits being able to succeed. Suddenly not just those that did
2 things but also those that did 1 thing.

So the assumption is to have a super sophisticated browser exploit for
which an attacker most likely spent several days to find it and then the
PATH setting will make it so much harder that the exploit will not
succeed? There are a lot more real challenges that attackers have to face.

Most users will use .bashrc and since it would be the file that is under
discussion here, only users that use it would be affected by the change.
Also attackers do not need a fancy algorithm, they can just manipulate
several files instead of doing sophisticated checks.

Even manipulating one, let alone several files, is already more
sophisticated than merely dropping one file.

echo echo pwned >> ~/.i18n does both (appending or creating a file, not
really more sophisticated). And this just works regardless of the PATH
setting.

If I was writing malware, I would be much happier with just being able
to drop a file in ~/bin or ~/.local/bin than doing the research on where
PATH is actually being set, and then getting the `sed` right, and all
that **without** being immediately discovered (eg. because I broke the
syntax or caused error).

If the attacker can already call sed, then they do not need to drop a
binary. Also they do not need to research where PATH is actually set.

My point is that security is not a black & white concept.

It's a float, not a bool. And I'm not arguing about the amount, but
merely against the black & white thinking. With all respect, to me it
sounds kinda like saying "why wash my hands when diseases can spread
through air".

The initial theory in this thread was that it is a significant security
risk. And all the arguments for this are either "it's obvious" or are
based on arbitrarily constructed scenarios. If you are saying it just
makes a minor impact, then we do not need to discuss further because
this is good enough for me.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6TITAQ6H2ZN25HXMN5B4NIN7FFIG2TYH/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-15 Thread Alois Mahdal

On 06/15/2018 11:24 AM, Till Maas wrote:
> ...]
> 
>> What I'm trying to say is that with these kinds of attack (like viruses,
>> or exploits on massively accessed page), there is inevitably going to be
>> some sort of economic decision on side of author affecting how "smart"
>> they want the code to be.
>>
>> Thus, every little step you're making towards "easier" translates to
>> dumber exploits being able to succeed.  Suddenly not just those that did
>> 2 things but also those that did 1 thing.
> 
> So the assumption is to have a super sophisticated browser exploit for
> which an attacker most likely spent several days to find it and then the
> PATH setting will make it so much harder that the exploit will not
> succeed? There are a lot more real challenges that attackers have to face.

The attacker could have looked up the exploit on the web.

I think you keep putting some kind of base standard on the hypothetical
attacker and then your argument is "if they can do X then they can do
Y".  Because we're both SW engineers, the relation between X and Y is
obvious to us, so yeah, anybody who would do X would totally obviously
also do Y.  Sure, we've been there so many times we don't even think
about it.

OTOH, I don't think that's the best way to think about security.  There
are no standards.   The amount of code (dedicated to Linux) could
totally be just that single line, writing the payload to .local/bin.
By including the path in default $PATH, you are allowing also the
on-bit-dumber attack to succeed (... now with all Fedora users, yay!...)

>> My point is that security is not a black & white concept.
>>
>> It's a float, not a bool.  And I'm not arguing about the amount, but
>> merely against the black & white thinking.  With all respect, to me it
>> sounds  kinda like saying "why wash my hands when diseases can spread
>> through air".
> 
> The initial theory in this thread was that it is a significant security
> risk. And all the arguments for this are either "it's obvious" or are
> based on arbitrarily constructed scenarios. If you are saying it just
> makes a minor impact, then we do not need to discuss further because
> this is good enough for me.

I'm saying there is some impact.  I'm not aware of any meaningful way to
measure it, but I don't think it's necessary: IMHO even making a "minor"
impact is already bad idea.

Especially if I don't really see any convincing reason why this should
be done.

The "bug" with /usr/bin/pip should IMO be fixed with /usr/bin/pip--IIUC
it's this bin that starts to conflate system libs with stuff under $HOME
(My guess is you could have this kind of breakage even in a way
unrelated to $PATH.)

Thanks,
aL.

-- 
Alois Mahdal 
Platform QE Engineer at Red Hat, Inc.
#brno, #daemons, #preupgrade
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QSYC4DFUAV7MIOAXXDHWBYIF2C6FF7KT/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-15 Thread Björn Persson

Tomasz Kłoczko wrote:
> Many people here gently been pointing on the issue without showing
> real POC how to use this.
> I think that it may force someone to put publically some POC showing
> how to use this.
> I see almost between the lines that I'm not only person here which
> such POC already _has_.

Please post your proof of concept so that people can discuss some
actual code instead of vague and unsubstantiated claims.

Don't forget that if your proof of concept can be modified to either
overwrite or append to ~/.bashrc, then it's irrelevant to this debate.

Björn Persson


pgpa4HLeeYGJo.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BT3UNOOMIRGPA4LSIIQONHIR5VEOJT3Z/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-15 Thread Robert Marcano

I am late to the discussion, and a lot of them are related to the 
security implications. I am more worried about users overriding 
dependencies of other programs. Let me explain with a hypothetical case:


1- There is a system installed application that manipulates PDFs and has 
a requirement to Ghostscript.
2- User is a JavaScript developer and install a tool named Google 
Sanitizer (fake name, npm install gs) and ends with a command named gs 
on the PATH overriding the system installed gs.
3- The PDF application start to fail with weird error messages, and new 
bugzilla entries are added.


What are the policies of those other distributions when packaging 
applications?, Do they force packagers to use absolute paths to their 
dependencies? Fedora currently doesn't do that, and I like that 
dependencies are called taking into account the PATH and not with 
absolute paths, but until now all Fedora packagers assume that ~/.bin 
and ~/.local/bin are not interfering by default with system installed 
applications




On 06/07/2018 04:21 AM, Sorin Sbarnea wrote:

Well said, there is no catchy name for this (virtual) security threat. We will 
have to let one of those that oppose this proposal to find a caching name 
(PATHEXIT?), maybe even build a paper explaining how to mitigate it.

I am bit disappointed because other distributions fixed it, even twice after a 
temporary regression due to a mistake. We never did it.

Now that we have a change proposal, how to continue? To get it accepted or 
rejected, is there a way/process that we need to follow?

Should we maybe add a section to the document with supporters and opposers 
where people can record themselves?

Thanks
Sorin



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VXFYSGI372TMRE5YRATKR4SKV4LXOMDV/


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VHN7IUOEIVKGZJZEOTPUOY6ACWMSEV4D/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-15 Thread Tomasz Kłoczko

On Thu, 14 Jun 2018 at 17:53, Zbigniew Jędrzejewski-Szmek
 wrote:
[..]
> We put the bar for _security_ measures much higher then mere inconvenience.
> In fact we know that users have been installing software in ~/
> successfully before this change, and it doesn't allow them to do
> anything they couldn't do before. Likewise, it doesn't allow attackers
> to do anything new. So people who consider this irrelevant for security
> assume that mere inconvenience _is not_ a hurdle for the attacker.
> Nevertheless, mere inconvenience _is_ a problem for many users.

It is huge difference between what exact users are doing with
distribution resources and what kind of new possibilities opens OOTB
set of distribution settings.
If someone wants to keep own savings in the tin on the front of his
home that it is someone private business but please do not ask nearest
bank to do the same!!!

Puting any paths on the FRONT of the $PATH which _does not point to
the paths_ where all distribution executables are installed is nothing
more like opening pandora box.
Many people here gently been pointing on the issue without showing
real POC how to use this.
I think that it may force someone to put publically some POC showing
how to use this.
I see almost between the lines that I'm not only person here which
such POC already _has_.

_Nothing_ in distribution resources so far REQUIRES to have ANY
ADDITIONAL paths on the front of the $PATH which are not pointing to
/usr/{,s}bin.
Can someone disprove above line or show me exact package which needs
such settings?

And again: this is not about what some persons wants to have but what
distribution resources (as finite machine with set of possible state
strong as continuum) requires.
If anyone would be able to agree with this should automatically cause
ACTION getting rid of those paths out of distribution OOTB settings.

If some users want to have paths like ~/.local/bin,
/usr/local{bin,sbin} on the the front of the $PATH it is possible to
do this by install additional package like fedora-for-vegans. Isn't
it? In such package with altering $PATH should land whole /usr/local
tree.
All talks about making some end users life "easier" (whatever it
means) IMO is pure BS/bollocks.
I think that such real demand to "make Fedora eazier" is highly
overestimated or over exaggerated.
Let's see how many people will be using such package concisely to
recognize REAL demand.

Nevertheless still no one answered on very simple question. So I'll repeat it:

Why Fedora _must_ offer OOTB ~/.local/bin, /usr/local{s,}bin paths on
the front of the $PATH in OOTB settings?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UPZORYRVRSUF6DM2JLKRDPPHHMJDUWF7/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-14 Thread Alois Mahdal

On 06/14/2018 11:37 PM, Till Maas wrote:
> Hi,
> 
> On Thu, Jun 14, 2018 at 04:19:27PM +0200, Alois Mahdal wrote:
> 
>> On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote:
> 
>> What about attack success rate?
> 
>> But if the attacker is some browser exploit able to take a shot at many
>> users (not knowing what their OS, let alone default $PATH is), then I
> 
> The browser knows the OS, see the User-Agent header, for example:
> User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
> Name
> 
> Also the PATH would be in the browser environment, so easy to access,
> too. However, if this information is not available to the attacker, why
> would they know the value of $HOME/bin or $HOME/.local/bin? They would
> have to know the user's username for this. IMHO these are not convincing
> assumptions.

Those are not assumptions.  It would be incorrect to assume that.

What I'm trying to say is that with these kinds of attack (like viruses,
or exploits on massively accessed page), there is inevitably going to be
some sort of economic decision on side of author affecting how "smart"
they want the code to be.

Thus, every little step you're making towards "easier" translates to
dumber exploits being able to succeed.  Suddenly not just those that did
2 things but also those that did 1 thing.

>> believe every next, more sophisticated step is less likely to be
>> included.  For example, they might not really feel it worth to include a
>> working algorithm to look at whether user uses .bashrc, .xsessionrc,
>> .zsh, .profile or whatnot.  Ie., leaving out ~/.local/bin would result
>> in **worse success rate** for them.
> 
> Most users will use .bashrc and since it would be the file that is under
> discussion here, only users that use it would be affected by the change.
> Also attackers do not need a fancy algorithm, they can just manipulate
> several files instead of doing sophisticated checks.

Even manipulating one, let alone several files, is already more
sophisticated than merely dropping one file.

If I was writing malware, I would be much happier with just being able
to drop a file in ~/bin or ~/.local/bin than doing the research on where
PATH is actually being set, and then getting the `sed` right, and all
that **without** being immediately discovered (eg. because I broke the
syntax or caused error).

~~

My point is that security is not a black & white concept.

It's a float, not a bool.  And I'm not arguing about the amount, but
merely against the black & white thinking.  With all respect, to me it
sounds  kinda like saying "why wash my hands when diseases can spread
through air".

Thanks,
aL.

-- 
Alois Mahdal 
Platform QE Engineer at Red Hat, Inc.
#brno, #daemons, #preupgrade
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OXYOC7KAC737CAKKHQAGOSEST5HHSKJ6/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-14 Thread Till Maas

Hi,

On Thu, Jun 14, 2018 at 04:56:32PM -0400, Stephen John Smoogen wrote:

> Look, people keep asking why it was like this. I am trying to explain
> it. I am not defending it or saying we have to keep doing it that

Thank you very much. I appreciate it to know the history and see that I
am not missing something important. It is now considered and we seem to
agree about the irrelevant security implications for current systems.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z7DHPKBVRDSJXELF4FVC7RH755FBV2X7/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-14 Thread Till Maas

Hi,

On Thu, Jun 14, 2018 at 04:19:27PM +0200, Alois Mahdal wrote:

> On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote:

> What about attack success rate?

> But if the attacker is some browser exploit able to take a shot at many
> users (not knowing what their OS, let alone default $PATH is), then I

The browser knows the OS, see the User-Agent header, for example:
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Name

Also the PATH would be in the browser environment, so easy to access,
too. However, if this information is not available to the attacker, why
would they know the value of $HOME/bin or $HOME/.local/bin? They would
have to know the user's username for this. IMHO these are not convincing
assumptions.

> believe every next, more sophisticated step is less likely to be
> included.  For example, they might not really feel it worth to include a
> working algorithm to look at whether user uses .bashrc, .xsessionrc,
> .zsh, .profile or whatnot.  Ie., leaving out ~/.local/bin would result
> in **worse success rate** for them.

Most users will use .bashrc and since it would be the file that is under
discussion here, only users that use it would be affected by the change.
Also attackers do not need a fancy algorithm, they can just manipulate
several files instead of doing sophisticated checks.

And again, as I already wrote, either ~/.bashrc is affected or not, you
cannot properly argue that it is affected in the way that it is read to
set he path but is not affected in the way that it will not be read
anymore after an attack.

>  *  (A) user doing something and knowing what & why,
>  *  (B) user copy/pasting some info from (untrusted?) github README.md,
>  *  (C) an (untrusted?) program run by user intentionally,
>  *  (D) malware running via exploit.
> 
> And if you make the change in $Subj, you can only make it for all of the
> above or none.
> 
> Inconvenience is not that much of a problem for (A), because it's not
> likely that they would know what they're doing and not recognize why
> it's not working (and blame Fedora).
> 
> Making it more convenient for (B) and (C) is IMO not worth given that
> we'd also make (D) more likely to succeed.

If there is already malicious code running with access the user's home
directory, the PATH setting is the least problem for the user because
the assumed problem for the PATH setting was that it would allow
attackers to get code executed.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X5NXDI2THGPZ4O6IBMS3XM55H4JYRYBV/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-14 Thread Stephen John Smoogen

On 14 June 2018 at 16:23, Till Maas  wrote:
> On Wed, Jun 13, 2018 at 05:28:03PM -0400, Stephen John Smoogen wrote:
>

>> and some other remote filesystem which were common in universities and
>> thought safe by itself. Or the attack would be done by controlling one
>> host with root permissions and using NFS or some other global
>> filesystems to put a trojan in one system and then getting the admin
>> to execute it on a different system. This was why it was a security
>
> I do not follow why the attacker would only have access to ~/bin or
> ~/.local/bin and can only add files there but not read or modify other
> files.
>

I have seen all kinds of weird defaults in 'helper' programs where it
wouldn't allow you to edit or overwrite existing files, but would
allow you to drop in new things in some subdirectory. Usually it is
trying to be helpful, and in most cases would not be a problem.. the
issue is getting it to chain-attack things so that you get what you
want by looking for weaknesses.

Look, people keep asking why it was like this. I am trying to explain
it. I am not defending it or saying we have to keep doing it that
way... this is just that various tools have in the past been overly
helpful and various security guidelines were designed to assume they
will be again and that the OS should make the user's default
environment as safe as possible.

The problem here is that most of those guidelines were written for a
different age where you have 1000's of people on the same machine and
hundreds of machines mounting shared disks which might allow chain
attacks. Those sites are not a place you find Fedora because by the
time you rolled out a version all your bugs are closed as EOL. They
are also not the problems that modern laptop users end up with as just
the flatpack/snap model says most of the applications you are going to
really use are in your home directory anyway.

>> finding for a long time in various checklists that user controlled bin
>> directories needed to be at the end of the path. It was also linked to
>
> IMHO "it is on a checklist" without proper justification is probably
> just security theater. There are enough possibilities to manipulate

I won't disagree it isn't security theatre. I also know that this is
the sort of checkmark which gets an OS removed from being used in
various sites and major fines for it. This is not as much a thing for
us to deal with as the people who may want to deploy it in various
environments where that is a problem. The change approval process
should be enough notification.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSQWM6FUCXJ2GJTGCSLAJG4DS6NXJW3N/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-14 Thread Till Maas

On Wed, Jun 13, 2018 at 05:28:03PM -0400, Stephen John Smoogen wrote:

> The usual culprit in the past has been where an attacker gets access
> via a chrooted or container environment where they only have access to
> a limited set of directories. A long time ago this was done via ftp

I read this as there is an actual security vulnerability to begin with.

> and some other remote filesystem which were common in universities and
> thought safe by itself. Or the attack would be done by controlling one
> host with root permissions and using NFS or some other global
> filesystems to put a trojan in one system and then getting the admin
> to execute it on a different system. This was why it was a security

I do not follow why the attacker would only have access to ~/bin or
~/.local/bin and can only add files there but not read or modify other
files.

> finding for a long time in various checklists that user controlled bin
> directories needed to be at the end of the path. It was also linked to

IMHO "it is on a checklist" without proper justification is probably
just security theater. There are enough possibilities to manipulate
files in $HOME and it usually contains the important user data so that
it should be protected properly so that one can properly assume that
only the user or administrators can access the data therein. AFAIK
selinux does this already and admins need to explicitly label
directories to allow protected services to access them. And this
whitelisting approach is the right thing to do from a security
perspective instead of trying to blacklist useful features for a
IMHO negligible or imaginary security gain.

All in all, there are already a lot of possibilities to escalate from
write access to $HOME to code-execution regardless of ~/bin or
~/.local/bin that I strongly believe that $HOME needs to be secured and
considered to be safe for their user. Otherwise I would like to see CVEs
for ~/bin being already in the PATH, since it can still contain typos of
common commands or commands that are not yet installed (and there is a
package kit plugin that shows that people will type commands of packages
that are not yet installed), for ~/.i18n (try test -e ~/i18n || echo
echo pwned > ~/.i18n if you wonder why), for ~/.ssh/authorized_keys to
allow login access for local users or ~/.ssh/config for allowing the
ProxyCommand directive. There are endless possibilities here.

> the reason not to put . in the path.

If there is a directory in the PATH that is controlled by other users,
it is very likely a problem, therefore adding "." there is bad.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P3SR4C7RUMRNTRPDMSVRZ6J2WNMDHYM5/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-14 Thread Alois Mahdal

(Again, I'm not infosec expert,  I'm just pulling from what I've
randomly heard/read/learned through my time in QA and SW engineering.)

On 06/14/2018 08:40 AM, Zbigniew Jędrzejewski-Szmek wrote:
> [...]
> hatever their privelege level might be.
>>>
>>> Executable directory? If you have power over user $HOME, you can change
>>> user's $PATH.
>>
>> Is it so easy, though?
>>
>> I've seen many examples with .bashrc, but .bashrc only does it for bash
>> (and only in interactive mode, IIRC).  One has to do it for something
>> like .xsessionrc -- frankly I'm not sure if there is such file that applies.
>>
>> OTOH, by adding .local/bin, the attacker does not have to care where (or
>> how) to set the path, they really only need to drop new file.
>>
>> I guess my point is that it won't make attacks possible (they already
>> are), but it might be making them easier.
> 
> That's a very correct observation. In fact, this is the whole purpose of
> this change: to make installing arbitrary scripts to be executed by the
> user _easy_! So anyone who is arguing that this makes it so much easier
> for the attacker, are also arguing that this makes it so much easier for
> the user.
> 
> We put the bar for _security_ measures much higher then mere inconvenience.
> In fact we know that users have been installing software in ~/
> successfully before this change, and it doesn't allow them to do
> anything they couldn't do before. Likewise, it doesn't allow attackers
> to do anything new. So people who consider this irrelevant for security
> assume that mere inconvenience _is not_ a hurdle for the attacker.

What about attack success rate?

OK, if it's a targeted, 1-on-1 attack, then attacker will either succeed
or fail, so, sure, inconvenience is almost irrelevant because they will
certainly invest the extra bit to look at pstree or something---to know
where to hit.  So yeah, that's off the table.

But if the attacker is some browser exploit able to take a shot at many
users (not knowing what their OS, let alone default $PATH is), then I
believe every next, more sophisticated step is less likely to be
included.  For example, they might not really feel it worth to include a
working algorithm to look at whether user uses .bashrc, .xsessionrc,
.zsh, .profile or whatnot.  Ie., leaving out ~/.local/bin would result
in **worse success rate** for them.

> Nevertheless, mere inconvenience _is_ a problem for many users.

Well, so what?  Missing an opportunity to make it easier for user to
take down the shields?  I'm fine with that.

Note that "user" is not always just "someone doing something and knowing
what".  Take any chain of actions, and assess what they mean from
security POV.  It is my belief that these are impossible to distinguish:

 *  (A) user doing something and knowing what & why,
 *  (B) user copy/pasting some info from (untrusted?) github README.md,
 *  (C) an (untrusted?) program run by user intentionally,
 *  (D) malware running via exploit.

And if you make the change in $Subj, you can only make it for all of the
above or none.

Inconvenience is not that much of a problem for (A), because it's not
likely that they would know what they're doing and not recognize why
it's not working (and blame Fedora).

Making it more convenient for (B) and (C) is IMO not worth given that
we'd also make (D) more likely to succeed.

Thanks,
aL.

PS: And if (B) complains, we should rather try to educate them and not
just do whatever they wish.  This is OS, not McDonald's restaurant.

-- 
Alois Mahdal 
Platform QE Engineer at Red Hat, Inc.
#brno, #daemons, #preupgrade
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ONMQO7K7PH2DI7DYRKKD6MG3VGLX44BO/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-14 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Jun 13, 2018 at 06:28:47PM +0200, Alois Mahdal wrote:
> Hi,
> 
> I'm no infosec expert, but...
> 
> On 06/12/2018 07:31 PM, Miro Hrončok wrote:
> > 
> > On 12.6.2018 19:20, Howard Howell wrote:
> >> I haven't followed all of this thread, too self busy.  However there is
> >> a security argument.  If you have a local executable directory, then
> >> the capability for malicious software to attach is wide open for that
> >> user, whatever their privelege level might be.
> > 
> > Executable directory? If you have power over user $HOME, you can change
> > user's $PATH.
> 
> Is it so easy, though?
> 
> I've seen many examples with .bashrc, but .bashrc only does it for bash
> (and only in interactive mode, IIRC).  One has to do it for something
> like .xsessionrc -- frankly I'm not sure if there is such file that applies.
> 
> OTOH, by adding .local/bin, the attacker does not have to care where (or
> how) to set the path, they really only need to drop new file.
> 
> I guess my point is that it won't make attacks possible (they already
> are), but it might be making them easier.

That's a very correct observation. In fact, this is the whole purpose of
this change: to make installing arbitrary scripts to be executed by the
user _easy_! So anyone who is arguing that this makes it so much easier
for the attacker, are also arguing that this makes it so much easier for
the user.

We put the bar for _security_ measures much higher then mere inconvenience.
In fact we know that users have been installing software in ~/
successfully before this change, and it doesn't allow them to do
anything they couldn't do before. Likewise, it doesn't allow attackers
to do anything new. So people who consider this irrelevant for security
assume that mere inconvenience _is not_ a hurdle for the attacker.
Nevertheless, mere inconvenience _is_ a problem for many users.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MGVABGXS3DT74MELLOR64VXOAVHUQ236/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Stephen John Smoogen

On 13 June 2018 at 17:34, Samuel Sieb  wrote:
> On 06/13/2018 02:28 PM, Stephen John Smoogen wrote:
>>
>> directories needed to be at the end of the path. It was also linked to
>> the reason not to put . in the path.
>
>
> I thought the reason to not put . in the path was because you could be
> looking in someone else's folder and they could have put an executable with
> the same name as a usual system one in there.  (Or a misspelling of one.)
> Generally more applicable to an admin than a user though.

I was going more about that the . in path was a substitution attack
and that was as far as I was going to take the analogy.



> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JGV23E5SAEMGO4B5Y3IICDU6FPQFPIN3/



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZJQZYWIXZPKV6XWUE2IM4X4P2WXNWRD3/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Samuel Sieb


On 06/13/2018 02:28 PM, Stephen John Smoogen wrote:

directories needed to be at the end of the path. It was also linked to
the reason not to put . in the path.


I thought the reason to not put . in the path was because you could be 
looking in someone else's folder and they could have put an executable 
with the same name as a usual system one in there.  (Or a misspelling of 
one.)  Generally more applicable to an admin than a user though.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JGV23E5SAEMGO4B5Y3IICDU6FPQFPIN3/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Stephen John Smoogen

On 13 June 2018 at 17:04, Till Maas  wrote:
> On Tue, Jun 12, 2018 at 08:43:06AM -0400, Matthew Miller wrote:
>> On Tue, Jun 12, 2018 at 07:50:29AM -0400, Nico Kadel-Garcia wrote:
>> > The simple fact is that "sudo" inherits $HOME and $PATH by default.
>>
>> Not in Fedora's default configuration. And, this proposal increases my
>> support for keeping that as it is (with secure_path set).
>
> I did not see a convincing argument or explanation why there is a
> critical security issue with sudo and this change, even when sudo would
> inherit $HOME and $PATH. Who is the attacker that can drop files only in
> $HOME/.local/bin or $HOME/bin not not in other directories, cannot
> append existing files and does not yet have elevated access on the
> system.
>

The usual culprit in the past has been where an attacker gets access
via a chrooted or container environment where they only have access to
a limited set of directories. A long time ago this was done via ftp
and some other remote filesystem which were common in universities and
thought safe by itself. Or the attack would be done by controlling one
host with root permissions and using NFS or some other global
filesystems to put a trojan in one system and then getting the admin
to execute it on a different system. This was why it was a security
finding for a long time in various checklists that user controlled bin
directories needed to be at the end of the path. It was also linked to
the reason not to put . in the path.

> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LJEJ3WYUA7UTU2HBRLG5MMDNNOPY5KKN/

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GQFBASWQOYCGLPLEZ7UMXU7NN5FHPABS/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Till Maas

On Tue, Jun 12, 2018 at 08:43:06AM -0400, Matthew Miller wrote:
> On Tue, Jun 12, 2018 at 07:50:29AM -0400, Nico Kadel-Garcia wrote:
> > The simple fact is that "sudo" inherits $HOME and $PATH by default.
> 
> Not in Fedora's default configuration. And, this proposal increases my
> support for keeping that as it is (with secure_path set).

I did not see a convincing argument or explanation why there is a
critical security issue with sudo and this change, even when sudo would
inherit $HOME and $PATH. Who is the attacker that can drop files only in
$HOME/.local/bin or $HOME/bin not not in other directories, cannot
append existing files and does not yet have elevated access on the
system.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LJEJ3WYUA7UTU2HBRLG5MMDNNOPY5KKN/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Till Maas

Hi,

On Wed, Jun 13, 2018 at 06:28:47PM +0200, Alois Mahdal wrote:

> I've seen many examples with .bashrc, but .bashrc only does it for bash
> (and only in interactive mode, IIRC).  One has to do it for something
> like .xsessionrc -- frankly I'm not sure if there is such file that applies.
>
> OTOH, by adding .local/bin, the attacker does not have to care where (or
> how) to set the path, they really only need to drop new file.

we are talking about a change in ~/.bash_profile here which sources
~/.bashrc. If you are thinking of scenarios where these files are not
sourced, then the PATH is not changed in that scenarios. Therefore these
scenarios would not matter here.

Also from an attacker's perspective: The attacker can just change
multiple files if necessary.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QPM57FSMJCBIZXDA2JGUHAPMVUJFX7AH/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Chris Adams

Once upon a time, Alois Mahdal  said:
> I've seen many examples with .bashrc, but .bashrc only does it for bash
> (and only in interactive mode, IIRC).  One has to do it for something
> like .xsessionrc -- frankly I'm not sure if there is such file that applies.

The desktop environment is run via the user's login shell - setting
variables in the shell init files does get applied to GUI programs.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CGBGLONPFK2UWSS3OB7A2BZ52MZ7UA4X/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Alois Mahdal

Hi,

I'm no infosec expert, but...

On 06/12/2018 07:31 PM, Miro Hrončok wrote:
> 
> On 12.6.2018 19:20, Howard Howell wrote:
>> I haven't followed all of this thread, too self busy.  However there is
>> a security argument.  If you have a local executable directory, then
>> the capability for malicious software to attach is wide open for that
>> user, whatever their privelege level might be.
> 
> Executable directory? If you have power over user $HOME, you can change
> user's $PATH.

Is it so easy, though?

I've seen many examples with .bashrc, but .bashrc only does it for bash
(and only in interactive mode, IIRC).  One has to do it for something
like .xsessionrc -- frankly I'm not sure if there is such file that applies.

OTOH, by adding .local/bin, the attacker does not have to care where (or
how) to set the path, they really only need to drop new file.

I guess my point is that it won't make attacks possible (they already
are), but it might be making them easier.

Thanks,
aL.

-- 
Alois Mahdal 
Platform QE Engineer at Red Hat, Inc.
#brno, #daemons, #preupgrade
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JOKH54HGNPJQJYANZKWXKYUF2VBOLQJJ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Daniel P . Berrangé

On Wed, Jun 13, 2018 at 11:17:25AM +0200, Reindl Harald wrote:
> 
> 
> Am 13.06.2018 um 11:11 schrieb Daniel P. Berrangé:
> > On Tue, Jun 12, 2018 at 08:00:26PM +0200, Reindl Harald wrote:
> >>
> >> Am 12.06.2018 um 19:45 schrieb Daniel P. Berrangé:
> >>> On Tue, Jun 12, 2018 at 10:20:46AM -0700, Howard Howell wrote:
>  I haven't followed all of this thread, too self busy.  However there is
>  a security argument.  If you have a local executable directory, then
>  the capability for malicious software to attach is wide open for that
>  user, whatever their privelege level might be.
> 
>  Most businesses that have linux in their suite, won't want a ~/.bin
>  anywhere in their organization.
> >>>
> >>> If a malicious attacker have privileges to create/modify $HOME/.bin/foo,
> >>> then they will also have privileges to modify $HOME/.bashrc to add any
> >>> directory they wish to $PATH. So that security argument doesn't hold water
> >>
> >> bullshit - man chattr
> >>
> >> [root@srv-rhsoft:~]$ touch /home/harry/.bashrc
> >> touch: setting times of '/home/harry/.bashrc': Operation not permitted
> >>
> >> so and now tell me how you override "ls" on my system until some fool
> >> adds a user-writeable directory in front of $PATH i am not aware
> > 
> > If you're willing to make custom modifications to prevent user writing
> > to their own $HOME, then there's no reason why you can't set a different
> > $PATH or also use chattr to prevent use of $HOME/.local/bin
> 
> you don't get it - the more unsecure the defaults are the more likely it
> is someone forget such a crazy default like "every random idiot can drop
> a binary which overrides basic commands"

I completely understand this. If you want to argue that there are things
we can do to make Fedora more secure by default ,that is great. My point
was about the impact of this proposed change, on the current Fedora
defaults, and in that context the proposal does not make Fedora less
secure.

> in 2018 systems have to become *more secure* insteal less just because
> some crap software rely on that don't get fixed - in which languages was
> the shit from the discussion written and don#t they provide something
> better than fuckup PATH to fix applications?

Please moderate your language, this is totally inappropriate.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IAMNVQ6ZF22FRSCLLMX3NGTOMXR5E3TB/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-13 Thread Daniel P . Berrangé

On Tue, Jun 12, 2018 at 08:00:26PM +0200, Reindl Harald wrote:
> 
> 
> Am 12.06.2018 um 19:45 schrieb Daniel P. Berrangé:
> > On Tue, Jun 12, 2018 at 10:20:46AM -0700, Howard Howell wrote:
> >> I haven't followed all of this thread, too self busy.  However there is
> >> a security argument.  If you have a local executable directory, then
> >> the capability for malicious software to attach is wide open for that
> >> user, whatever their privelege level might be.
> >>
> >> Most businesses that have linux in their suite, won't want a ~/.bin
> >> anywhere in their organization.
> > 
> > If a malicious attacker have privileges to create/modify $HOME/.bin/foo,
> > then they will also have privileges to modify $HOME/.bashrc to add any
> > directory they wish to $PATH. So that security argument doesn't hold water
> 
> bullshit - man chattr
> 
> [root@srv-rhsoft:~]$ touch /home/harry/.bashrc
> touch: setting times of '/home/harry/.bashrc': Operation not permitted
> 
> so and now tell me how you override "ls" on my system until some fool
> adds a user-writeable directory in front of $PATH i am not aware

If you're willing to make custom modifications to prevent user writing
to their own $HOME, then there's no reason why you can't set a different
$PATH or also use chattr to prevent use of $HOME/.local/bin.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DRUSEEQWQU6LJB3747D4RCYHWM3ZIOVE/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Matthew Miller

On Tue, Jun 12, 2018 at 08:26:52PM +0200, Miro Hrončok wrote:
> On 12.6.2018 20:15, Reindl Harald wrote:
> >>This is more like a security by obscurity approach. This "another layer"
> >>is just one step. It's like putting a duct tape over a keyhole and call
> >>it extra security
> >bullshit
> Thanks for the tone, it is very helpful.

Because of past behavior like this, Harald has been restricted from
posting to this list; he apparently replied and CC'd you on the
message. If you get harassing messages that fit that pattern in the
future, please do not respond but instead report to the Fedora Council.
Thank you.

And Harald: seriously. This is not how we conduct discussion in Fedora.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/64A7RPE34TUTHQ7UTAKDZZLK4IJ6CJXH/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 12.6.2018 20:15, Reindl Harald wrote:

This is more like a security by obscurity approach. This "another layer"
is just one step. It's like putting a duct tape over a keyhole and call
it extra security

bullshit

Thanks for the tone, it is very helpful.

when the exploit is naively written it just tries to put a binary in the
directory and on well configured system you don't put ANYTHING in front
of PATH

man chattr

[root@srv-rhsoft:~]$ touch /home/harry/.bashrc
touch: setting times of '/home/harry/.bashrc': Operation not permitted

Excellent. So the file is immutable. Since you were clever enough to
make it so, you probably care enough to change the line that prepends
the PATH in there. Or is that too complicated?

We are changing the default and we are saying that it will not lower the
security. If users want to make steps into increasing security that's
good. And we are not blocking them by this change.

but luckily Fedora was too long too stupid get rid of /bin and /sbin
after UsrMove so that i don't care about any defaults any longer

Funny how you don't care yet you keep sending the e-mails.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M32M74CLD6IIHR46XYCDKBJVRSL7GZP6/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH




On 12.6.2018 19:57, Reindl Harald wrote:



Am 12.06.2018 um 19:31 schrieb Miro Hrončok:


On 12.6.2018 19:20, Howard Howell wrote:

I haven't followed all of this thread, too self busy.  However there is
a security argument.  If you have a local executable directory, then
the capability for malicious software to attach is wide open for that
user, whatever their privelege level might be.


Executable directory? If you have power over user $HOME, you can change
user's $PATH. I don't know what this have to do with anything being
executable (but maybe I just didn't understand.)


so what - the more you need to change the harder a successful attack
becomes - google for layered security


This is more like a security by obscurity approach. This "another layer" 
is just one step. It's like putting a duct tape over a keyhole and call 
it extra security.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M6OIUDG2SKN2Q5IU2TFBHJNNF25JXZJA/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Daniel P . Berrangé

On Tue, Jun 12, 2018 at 10:20:46AM -0700, Howard Howell wrote:
> I haven't followed all of this thread, too self busy.  However there is
> a security argument.  If you have a local executable directory, then
> the capability for malicious software to attach is wide open for that
> user, whatever their privelege level might be.
> 
> Most businesses that have linux in their suite, won't want a ~/.bin
> anywhere in their organization.

If a malicious attacker have privileges to create/modify $HOME/.bin/foo,
then they will also have privileges to modify $HOME/.bashrc to add any
directory they wish to $PATH. So that security argument doesn't hold water.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B7DIN36VCWSFUBQBU7JXBBWWWUXSDN7X/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH



On 12.6.2018 19:20, Howard Howell wrote:

I haven't followed all of this thread, too self busy.  However there is
a security argument.  If you have a local executable directory, then
the capability for malicious software to attach is wide open for that
user, whatever their privelege level might be.


Executable directory? If you have power over user $HOME, you can change 
user's $PATH. I don't know what this have to do with anything being 
executable (but maybe I just didn't understand.)



Most businesses that have linux in their suite, won't want a ~/.bin
anywhere in their organization.


This is already in the PATH for ages.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JYUSHTQWFZJLJIEV2XHTLEEQ5F6DKVC7/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Howard Howell


On Tue, 2018-06-12 at 12:10 +0100, Tomasz Kłoczko wrote:
> On Mon, 11 Jun 2018 at 12:28, Miro Hrončok 
> wrote:
> [..]
> > See the change description.
> 
> OK So here is quoted original email with proposal.
> 
> "I'd like to propose putting the ~/.local/bin in front of the
> /usr/bin on
> the PATH.
> 
> Currently /usr/bin has priority over ~/.local/bin, which causes a
> [bug]
> where the old system-installed executable written in Python (from
> /usr/bin) is launched, but it finds new Python sources (installed
> into
> $HOME) which it doesn't work with and crashes.
> 
> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> 
> I believe the current configuration breaks the intuitive expectation
> that things installed closer to the user should take priority. That's
> for example how it works with Python.
> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
> 
> Does anyone see a reason not to prioritize ~/.local/bin over
> /usr/bin?"
> 
> At the end of the proposal is the question about potential reasons
> why
> this change should not be included, and answer on exactly this
> question has been provided in this thread several times in different
> forms and by more than one person.
> 
> Most of us knows that sometimes it is really hard to find answer on
> some question or prove some theories/thesis. Logick gives perfect
> tool
> to open such hard nuts sometimes instantly.
> https://proofwiki.org/wiki/Negation_of_Conditional_implies_Negation_o
> f_Consequent
> So called CPA (Conditional Proof Assumption) says that If it is hard
> to answer on the original question straight just try to negate
> original formula/postulat/question than continue work on negated one.
> I'll add to this thread kind of CPA question:
> 
> What this change fixes, improves or makes possible in context of
> pure/only distribution resources?
> 
> Second part of above question is really crucial. What started
> #1571650
> wend to "proposal" of the change of the distribution resources
> behaviour.
> Was it correct step? What if this ticket would be about "unexpected
> behavior" of the python in case of installing something in /opt? What
> about other prefixes? Does "positive reaction" on such "needs" should
> imply/justify opening discussion on fiddling in distribution OOTB
> $PATH???
> IMO definitely *NO*!!!
> 
> Just FTR: So far I was unable to find in any of the fredesktop.org or
> other specs (https://www.freedesktop.org/wiki/Software/) things like
> requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
> especially on the front of thes env variable). I would be really glad
> to find original reason why paths like /usr/local{bi,sbin} have been
> added to OOTB $PATH and why someone has been thinking that those
> paths
> should be added on the front of the $PATH.
> 
> I can only guess that most of the people reading this thread and
> still
> not able to identify any danger from security angle may be thinking
> that fiddling in the $PATH isn't dangerous or it may be dangerous
> only
> when someone is typing some commands into shell prompt.
> If it is like this this impression is wrong and I'm 100% sure at
> least
> few people (not only me) commenting in this thread could have no any
> difficulty to show that it is really only impression.
> 
> kloczek
> -- 
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/EI62XGJANQ4ZX3XC3MDQXY5T2UZLQGNY/
I haven't followed all of this thread, too self busy.  However there is
a security argument.  If you have a local executable directory, then
the capability for malicious software to attach is wide open for that
user, whatever their privelege level might be.

Most businesses that have linux in their suite, won't want a ~/.bin
anywhere in their organization.

Les H
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OLCYVX5L74NYFHJJJ76DB5O4MIE2KFPQ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Matthew Miller

On Tue, Jun 12, 2018 at 07:50:29AM -0400, Nico Kadel-Garcia wrote:
> The simple fact is that "sudo" inherits $HOME and $PATH by default.

Not in Fedora's default configuration. And, this proposal increases my
support for keeping that as it is (with secure_path set).

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3PTRM34L2DP7IT564I2FHMYVJGSFPSCC/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Kyle Marek

On 06/12/2018 07:50 AM, Nico Kadel-Garcia wrote:
> On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
>  wrote:
>
>> Just FTR: So far I was unable to find in any of the fredesktop.org or
>> other specs (https://www.freedesktop.org/wiki/Software/) things like
>> requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
>> especially on the front of thes env variable). I would be really glad
>> to find original reason why paths like /usr/local{bi,sbin} have been
>> added to OOTB $PATH and why someone has been thinking that those paths
>> should be added on the front of the $PATH.
> Most of them aren't worried enough about it, or don't have enough
> history to see underlying problems. Most think, and I'm pretty sure of
> this, that you've gotten the security explanations done repeatedly and
> seem to have ignored them. They're certainly not actually spelled out
> in your analysis.
>
> The simple fact is that "sudo" inherits $HOME and $PATH by default.
> Your proposed change would make privilege escalation attacks against
> sudo users much more trivial by opening up the attack surface for
> every binary in /bin or /usr/bin to be replaced by a local binary in
> ~/.local/bin/. The situation you're trying to resolve, where a
> powerful binary has intermingled components that may or not be matched
> by system components, has been resolved repeatedly by tools like rvm
> and pyvenv, by setting up a specific directory *not* enabled by
> default, but making setup for that less default enabled tool easy for
> the user to enable on a case by case basis.
>
> So, the risk of your change is high for others, the consequences are
> potentially *disastrous*,  and you've already got workarounds for your
> particular needs *without* touching other system behavior  If you
> really want it for youself as a user, which I do not recommend for
> such a tool, well, you can insist on doing it for your own individual
> needs on a case by case basis.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QHIKORMDVMA4JNRKYLO2M7LLLAY25R3U/

`sudo` inheriting the user's path is a security issue, in itself.

Also note that Fedora's default sudo config does not allow $PATH
inheritance, anyway.

See sudo(8), section "ENVIRONMENT": PATH    May be overridden by the
security policy.

kmarek@localhost.localdomain ~
$ sh -c 'echo $PATH'
/usr/libexec/python3-sphinx:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/kmarek/.local/bin:/home/kmarek/bin

kmarek@localhost.localdomain ~
$ sudo sh -c 'echo $PATH'
/sbin:/bin:/usr/sbin:/usr/bin

kmarek@localhost.localdomain ~
$ env PATH=/nonexistent /usr/bin/sudo env | grep ^PATH=
PATH=/sbin:/bin:/usr/sbin:/usr/bin

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NYKLV7AGO5OXLAWUSLYMNADJN5FITQM6/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Daniel P . Berrangé

On Tue, Jun 12, 2018 at 07:50:29AM -0400, Nico Kadel-Garcia wrote:
> On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
>  wrote:
> 
> > Just FTR: So far I was unable to find in any of the fredesktop.org or
> > other specs (https://www.freedesktop.org/wiki/Software/) things like
> > requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
> > especially on the front of thes env variable). I would be really glad
> > to find original reason why paths like /usr/local{bi,sbin} have been
> > added to OOTB $PATH and why someone has been thinking that those paths
> > should be added on the front of the $PATH.
> 
> Most of them aren't worried enough about it, or don't have enough
> history to see underlying problems. Most think, and I'm pretty sure of
> this, that you've gotten the security explanations done repeatedly and
> seem to have ignored them. They're certainly not actually spelled out
> in your analysis.
> 
> The simple fact is that "sudo" inherits $HOME and $PATH by default.
> Your proposed change would make privilege escalation attacks against
> sudo users much more trivial by opening up the attack surface for
> every binary in /bin or /usr/bin to be replaced by a local binary in
> ~/.local/bin/.

No, it doesn't increase the risk. If someone has privs to create
binaries in $HOME/.local/bin, then they can already change $HOME
and $PATH env vars. If this attack scenario is a concern, then
change sudo to not honour env variables like $HOME/$PATH at all.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QHL7XRN77UYAXOY5DT4SZ4T7YXT6EDPE/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH


On 12.6.2018 13:50, Nico Kadel-Garcia wrote:

On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
 wrote:


Just FTR: So far I was unable to find in any of the fredesktop.org or
other specs (https://www.freedesktop.org/wiki/Software/) things like
requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
especially on the front of thes env variable). I would be really glad
to find original reason why paths like /usr/local{bi,sbin} have been
added to OOTB $PATH and why someone has been thinking that those paths
should be added on the front of the $PATH.


Most of them aren't worried enough about it, or don't have enough
history to see underlying problems. Most think, and I'm pretty sure of
this, that you've gotten the security explanations done repeatedly and
seem to have ignored them. They're certainly not actually spelled out
in your analysis.

The simple fact is that "sudo" inherits $HOME and $PATH by default.
Your proposed change would make privilege escalation attacks against
sudo users much more trivial by opening up the attack surface for
every binary in /bin or /usr/bin to be replaced by a local binary in
~/.local/bin/. The situation you're trying to resolve, where a
powerful binary has intermingled components that may or not be matched
by system components, has been resolved repeatedly by tools like rvm
and pyvenv, by setting up a specific directory *not* enabled by
default, but making setup for that less default enabled tool easy for
the user to enable on a case by case basis.

So, the risk of your change is high for others, the consequences are
potentially *disastrous*,  and you've already got workarounds for your
particular needs *without* touching other system behavior  If you
really want it for youself as a user, which I do not recommend for
such a tool, well, you can insist on doing it for your own individual
needs on a case by case basis.


If somebody can write to your $HOME, they can change your $PATH. Hence 
the disaster is already happening and this change doesn't make it any 
more insecure than it already is.


Please read 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OXXC5NOZP37W2F6GHV6P5E6K22QHOBNJ/ 
- this has already been discussed there.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4FQJUIWIGHQJM5VFZO2E6IPFI45R2Z4U/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Nico Kadel-Garcia

On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
 wrote:

> Just FTR: So far I was unable to find in any of the fredesktop.org or
> other specs (https://www.freedesktop.org/wiki/Software/) things like
> requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
> especially on the front of thes env variable). I would be really glad
> to find original reason why paths like /usr/local{bi,sbin} have been
> added to OOTB $PATH and why someone has been thinking that those paths
> should be added on the front of the $PATH.

Most of them aren't worried enough about it, or don't have enough
history to see underlying problems. Most think, and I'm pretty sure of
this, that you've gotten the security explanations done repeatedly and
seem to have ignored them. They're certainly not actually spelled out
in your analysis.

The simple fact is that "sudo" inherits $HOME and $PATH by default.
Your proposed change would make privilege escalation attacks against
sudo users much more trivial by opening up the attack surface for
every binary in /bin or /usr/bin to be replaced by a local binary in
~/.local/bin/. The situation you're trying to resolve, where a
powerful binary has intermingled components that may or not be matched
by system components, has been resolved repeatedly by tools like rvm
and pyvenv, by setting up a specific directory *not* enabled by
default, but making setup for that less default enabled tool easy for
the user to enable on a case by case basis.

So, the risk of your change is high for others, the consequences are
potentially *disastrous*,  and you've already got workarounds for your
particular needs *without* touching other system behavior  If you
really want it for youself as a user, which I do not recommend for
such a tool, well, you can insist on doing it for your own individual
needs on a case by case basis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QHIKORMDVMA4JNRKYLO2M7LLLAY25R3U/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-12 Thread Tomasz Kłoczko

On Mon, 11 Jun 2018 at 12:28, Miro Hrončok wrote:
[..]
> See the change description.

OK So here is quoted original email with proposal.

"I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
the PATH.

Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed into
$HOME) which it doesn't work with and crashes.

[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650

I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.

Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?"

At the end of the proposal is the question about potential reasons why
this change should not be included, and answer on exactly this
question has been provided in this thread several times in different
forms and by more than one person.

Most of us knows that sometimes it is really hard to find answer on
some question or prove some theories/thesis. Logick gives perfect tool
to open such hard nuts sometimes instantly.
https://proofwiki.org/wiki/Negation_of_Conditional_implies_Negation_of_Consequent
So called CPA (Conditional Proof Assumption) says that If it is hard
to answer on the original question straight just try to negate
original formula/postulat/question than continue work on negated one.
I'll add to this thread kind of CPA question:

What this change fixes, improves or makes possible in context of
pure/only distribution resources?

Second part of above question is really crucial. What started #1571650
wend to "proposal" of the change of the distribution resources
behaviour.
Was it correct step? What if this ticket would be about "unexpected
behavior" of the python in case of installing something in /opt? What
about other prefixes? Does "positive reaction" on such "needs" should
imply/justify opening discussion on fiddling in distribution OOTB
$PATH???
IMO definitely *NO*!!!

Just FTR: So far I was unable to find in any of the fredesktop.org or
other specs (https://www.freedesktop.org/wiki/Software/) things like
requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
especially on the front of thes env variable). I would be really glad
to find original reason why paths like /usr/local{bi,sbin} have been
added to OOTB $PATH and why someone has been thinking that those paths
should be added on the front of the $PATH.

I can only guess that most of the people reading this thread and still
not able to identify any danger from security angle may be thinking
that fiddling in the $PATH isn't dangerous or it may be dangerous only
when someone is typing some commands into shell prompt.
If it is like this this impression is wrong and I'm 100% sure at least
few people (not only me) commenting in this thread could have no any
difficulty to show that it is really only impression.

kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EI62XGJANQ4ZX3XC3MDQXY5T2UZLQGNY/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-11 Thread Miro Hrončok

On 11.6.2018 13:05, Tomasz Kłoczko wrote:> I would be way more 
interested of real arguments about why someone is

trying to add those $PATH modifications.
So far only "argument is that someone proposed those changes without
justification except that some other people added something like this
to some "specification" in which is not possible to find what class of
the cases solves/handles/improves.


See the change description.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SCPV6ZYHSQIQIXX5WJTRIYA4WIKGZOIC/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-11 Thread Tomasz Kłoczko

On Sun, 10 Jun 2018 at 21:02, Sorin Sbarnea  wrote:
>
> Well said, there is no catchy name for this (virtual) security threat. We 
> will have to let one of those that oppose this proposal to find a caching 
> name (PATHEXIT?), maybe even build a paper explaining how to mitigate it.
>
> I am bit disappointed because other distributions fixed it, even twice after 
> a temporary regression due to a mistake. We never did it.
>
> Now that we have a change proposal, how to continue? To get it accepted or 
> rejected, is there a way/process that we need to follow?
>
> Should we maybe add a section to the document with supporters and opposers 
> where people can record themselves?

I would be way more interested of real arguments about why someone is
trying to add those $PATH modifications.
So far only "argument is that someone proposed those changes without
justification except that some other people added something like this
to some "specification" in which is not possible to find what class of
the cases solves/handles/improves.

kloczek
-- 
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G32OQODR4OD2NWUO7GUIGEORBX67XYY2/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-07 Thread Miro Hrončok


On 7.6.2018 10:37, Miro Hrončok wrote:

On 7.6.2018 10:21, Sorin Sbarnea wrote:
Now that we have a change proposal, how to continue? To get it 
accepted or rejected, is there a way/process that we need to follow?


Mark the change ready for wrangler.


I've just did.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YHNSK7ZUTGBJW5HDHX63HV2FMR4TUE6M/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-07 Thread Miro Hrončok


On 7.6.2018 10:21, Sorin Sbarnea wrote:

Now that we have a change proposal, how to continue? To get it accepted or 
rejected, is there a way/process that we need to follow?


Mark the change ready for wrangler.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G35X7MP6V4D5P6274DVUMHPOE5TYRXZK/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-06-07 Thread Sorin Sbarnea

Well said, there is no catchy name for this (virtual) security threat. We will 
have to let one of those that oppose this proposal to find a caching name 
(PATHEXIT?), maybe even build a paper explaining how to mitigate it.

I am bit disappointed because other distributions fixed it, even twice after a 
temporary regression due to a mistake. We never did it.

Now that we have a change proposal, how to continue? To get it accepted or 
rejected, is there a way/process that we need to follow?

Should we maybe add a section to the document with supporters and opposers 
where people can record themselves?

Thanks
Sorin


signature.asc
Description: Message signed with OpenPGP
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VXFYSGI372TMRE5YRATKR4SKV4LXOMDV/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On Tue, May 29, 2018 at 05:18:48PM +0100, Tomasz Kłoczko wrote:
> On 29 May 2018 at 15:24, Till Maas  wrote:

> > This is also not a serious security threat.
> >
> 
> And this claim bases on what kind of facts?
> Can you prove this?

Sure, there is no logo or catchy name for it.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EQ3EV2ICJNBYL5VW2BOHQGU6EGLVH42D/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 29 May 2018 at 15:24, Till Maas  wrote:

> Hi,
>
> On Tue, May 29, 2018 at 01:44:00PM +0100, Tomasz Kłoczko wrote:
>
> > Just try to grep across /usr for /usr/local. This is not only about
> $PATH.
> > Many scripts, programs or configuration files have HARDCODED checking
> > availability of some resources or executables in /usr/local before start
> > use those from /usr.
>
> This is also not a serious security threat.
>

And this claim bases on what kind of facts?
Can you prove this?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6PHYQR5PJQFUVG5UUM343H7AISJTNXOS/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH




On 29.5.2018 16:22, Tomasz Kłoczko wrote:
On 29 May 2018 at 13:57, Miro Hrončok > wrote:


On 29.5.2018 14:44, Tomasz Kłoczko wrote:

This connected with using env in many current packages adds next
batch of possibilities.


Agreed. Hence we try to fight env shebangs by brp scripts.


Problem is that this bpr script brs been already introduces something 
like few months ago.
Next day after new version of the redhat-rpm-config package with this 
brp script has been introduced someone should send ALL packages affected 
by this issue send as batch to rebuild..


Actually this was supposed to be covered by mass rebuild. However there 
are packages that FTBFS for ages.


See for example:

https://koji.fedoraproject.org/koji/packageinfo?packageID=15893

Now finally we will remove those:

https://fedoraproject.org/wiki/Fails_to_build_from_source



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OZJHS5732OK2LEESPCESBYE2AST4F5WE/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

Hi,

On Tue, May 29, 2018 at 01:44:00PM +0100, Tomasz Kłoczko wrote:

> Just try to grep across /usr for /usr/local. This is not only about $PATH.
> Many scripts, programs or configuration files have HARDCODED checking
> availability of some resources or executables in /usr/local before start
> use those from /usr.

This is also not a serious security threat.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N2N76QNPFMXCI7YUACCDNXKH3USQ6TOK/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 29 May 2018 at 13:57, Miro Hrončok  wrote:

> On 29.5.2018 14:44, Tomasz Kłoczko wrote:
>
>> This connected with using env in many current packages adds next batch of
>> possibilities.
>>
>
> Agreed. Hence we try to fight env shebangs by brp scripts.

Problem is that this bpr script brs been already introduces something like
few months ago.
Next day after new version of the redhat-rpm-config package with this brp
script has been introduced someone should send ALL packages affected by
this issue send as batch to rebuild..
Result is is that none of the Fedora packagers with proven packager
permissions are involved in such changes which should be done under "Shoot
And Forget".regime.
The same with not only critical changes but some improvements which should
be introduces in SAF mode/regime.
~Year ago I've initiated some of such changes and they never been finished
to the bottom of the list.

Few examples:

# (dnf -C repoquery --whatrequires initscripts; dnf -C repoquery
--whatrequires systemd)|sort|uniq -d| wc -l
25
# dnf -C repoquery --whatrequires initscripts| wc -l
66

Q: How long already systemd iis in use in Fedora?

# dnf -C repoquery --whatrequires /sbin/ldconfig| wc -l
18675

# dnf -C repoquery --whatrequires /sbin/install-info| wc -l
389

Almost no one removes bcond macroisation for EOSed <=F25 oe epel{4,5}
.
.
(I can make this list at least 3-4 times longer)

In other words: I've already lost faith that using env will be wiped out
because it is literally NULL focus of the Fedora Committees to coordinate,
control and report progress on such changes.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JDUP4EEAIJFVHAMFWVHOBJX4E4AUYLJB/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH


On 29.5.2018 14:44, Tomasz Kłoczko wrote:
This connected with using env in many current packages adds next batch 
of possibilities.


Agreed. Hence we try to fight env shebangs by brp scripts.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7YBMZXIM24FIOCS6QDRQFX4J7HS4IR2L/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 29 May 2018 at 10:37, Till Maas  wrote:

> Hi,
>
> On Tue, May 29, 2018 at 10:19:44AM +0100, Tomasz Kłoczko wrote:
>
> > distribution binaries is extremely dangerous, and I'm really surprised
> that
> > no one looks on those already discussed here issues (and few similar or
> > related) as SERIOUS SECURITY TREAT to whole distribution.
>
> IIRC enough people explained why these are not serious security threats.
>

This is nothing personal. Some people are unable to understand the subjects
above some level of the complexity or sometimes some classes of the
problems :(
Yes, I've already noticed that some people commenting in this thread really
do not understand the treat, and because some of those people are sometimes
responsible for making some crucial Fedora decisions this is nothing more
than yet another small crack in whole distribution maintenance process.

Just for the record: security risk which I'm talking about is straightly
related not with adding ~/.local/bin to $PATH, but with paths like
/usr/local/bin and /usr/local/sbin which are already used in the $PATH.
This connected with using env in many current packages adds next batch of
possibilities. However, all those possibilities became *few years ago*
suddenly opened/active only because what now is in the $PATH and because
some distribution binaries or scripts allows use programs from outside of
the distribution BEFORE using standard paths where executables are
installed by all packages.

$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin

Any compilation of the packages on the distro build systems, any execution
of the program without full; path in ALL scripts (check /etc/profile can
you find such programs called in script like this one) or most of the use
execve() with above $PATH in env is affected as well by what is in the
$PATH .. NOW!
Adding ~/.local/bin to the $PATH with the current level of the risk would
be barely noticeable.

Just try to grep across /usr for /usr/local. This is not only about $PATH.
Many scripts, programs or configuration files have HARDCODED checking
availability of some resources or executables in /usr/local before start
use those from /usr.

Something what started many decades ago (in U*nix epoch of the flint) in
the time when people have' been installing additional programs in
/usr/local prefix because they've been developing something or because
distributions where very small almost always was necessary to install
something now STILL is used without all those reasons.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5WFMTDCDJPQEEM64WZZ76CS23FWXQD4F/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH


On 29.5.2018 12:48, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, May 29, 2018 at 10:19:02AM +0100, Sorin Sbarnea wrote:

I ended up creating
https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
others to improve its description.


A very nice description. Can you add some hints on what needs to change
(/etc/profile?).


I've added it, it's /etc/skel/.bash_profile

On 29.5.2018 11:47, Till Maas wrote:
> awesome, I was about to do the same, therefore I added myself as second
> owner to express that I will support this.

I've done the same.

> Do you have an opinion about
> what to do with ~/bin, IMHO it should be prioritized, too. I am not sure
> if there is a real use case to keep it with lower priority. If there is,
> then I will add it to the proposal.

I think that this is the last thing that's needed. Technically, I think 
it should be prioritized too. See the end of detailed description.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OEQVACEPLYV2PSUKASLSJW4HOW5N7JU2/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-05-29 Thread Zbigniew Jędrzejewski-Szmek

> On Tue, May 29, 2018 at 10:19:02AM +0100, Sorin Sbarnea wrote:
> > I ended up creating
> > https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
> > others to improve its description.

A very nice description. Can you add some hints on what needs to change
(/etc/profile?).

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IWHKU5YQ5G3COKORYARFYECHORB65KKW/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

Hi,

On Tue, May 29, 2018 at 10:19:02AM +0100, Sorin Sbarnea wrote:
> I ended up creating
> https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
> others to improve its description.

awesome, I was about to do the same, therefore I added myself as second
owner to express that I will support this. Do you have an opinion about
what to do with ~/bin, IMHO it should be prioritized, too. I am not sure
if there is a real use case to keep it with lower priority. If there is,
then I will add it to the proposal.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SB7PIOBJ2NLV7GAQCVA53W6XYOPT7MPZ/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

Hi,

On Tue, May 29, 2018 at 10:19:44AM +0100, Tomasz Kłoczko wrote:

> distribution binaries is extremely dangerous, and I'm really surprised that
> no one looks on those already discussed here issues (and few similar or
> related) as SERIOUS SECURITY TREAT to whole distribution.

IIRC enough people explained why these are not serious security threats.

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6CPJXB6RQVA7E7AORKMQWCLNTVOIBVFE/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

On 29 May 2018 at 09:25, Miro Hrončok  wrote:

>
>
> On 29.5.2018 09:34, Sorin Sbarnea wrote:
>
>> What do we need to do to make Fedora do the right thing (add it to the
>> top of the list), just like Debian/Ubuntu. I am sure that they had similar
>> discussions and in the end they decided to do the right thing.
>>
>
> A Fedora change proposal.
>
> https://fedoraproject.org/wiki/Changes/Policy

Does such reply mean that maintainers of some critical packages like pam,
util-linux are completely not interested to even have opinion about the
subject or to provide expertise?
If it is the case rising the change proposal IMO does not make any sense.

Using env (still dnf shows that more than 250 packages is using
/usr/bin/env) or paths in $PATH pointing to the location where there is no
distribution binaries is extremely dangerous, and I'm really surprised that
no one looks on those already discussed here issues (and few similar or
related) as SERIOUS SECURITY TREAT to whole distribution.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3E72TSAQTN5WW3S7A2L2UJRVEFFP3SDP/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

2018-05-29 Thread Sorin Sbarnea

I ended up creating
https://fedoraproject.org/wiki/Changes/UserPathPrioritization and I invite
others to improve its description.

--
/sorin

On Tue, May 29, 2018 at 9:25 AM, Miro Hrončok  wrote:

>
>
> On 29.5.2018 09:34, Sorin Sbarnea wrote:
>
>> What do we need to do to make Fedora do the right thing (add it to the
>> top of the list), just like Debian/Ubuntu. I am sure that they had similar
>> discussions and in the end they decided to do the right thing.
>>
>
> A Fedora change proposal.
>
> https://fedoraproject.org/wiki/Changes/Policy
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VB2E4CRXYFXXISRWK2YXPVSTM4OWSAJO/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH