[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2021-10-26 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #103 from Bo Weaver  ---
(In reply to petrk from comment #102)
> That revert was stuck for a year. I don't see it going anywhere with
> dissatisfied users being called "vocal minority".
> 
> I'm not speaking for myself, as I don't mind doing stuff via terminal.
> However, KDE lately was aiming more towards new users. Why would they be
> forced to learn their way around console, or to keep different file manager
> just to edit some files in restricted areas?

I wrote about this back in 2019 and they aren't going to listen.  The
developers here seem to know better than you and me and are protecting us from
ourselves.  My best fix found is XFCE.  It is a great DE and the developers
don't mess with root access.  BTW I was a KDE user since the 90's and finally
gave up.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2020-05-12 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #96 from Bo Weaver  ---
(In reply to blueball from comment #95)
> So, this bug is pestering KDE users for a decade already. 
> 
> Is David Faure still alive or does he has other hobbies nowadays?
> 
> Isn't this a sign on the wall to NOT use KIO at all and revert back to the
> state that it just worked?

My best advice is change to XFCE and stop putting up with fools that think they
are Gods.  I did.

XFCE has come a long way and it is a stable secure DE and the developers listen
to their users.  XFCE is now the default DE for Kali for this reason.  The Kali
developers got tired of fixing there developers screw ups and went to XFCE.

Another good reason to change is these developers don't do proper security
testing of their code using the common tools of the industry.  Please read my
attached report in PDF from several months ago.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-plasma] [Bug 413299] Login fails for root

2020-01-31 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=413299

--- Comment #4 from Bo Weaver  ---

Don't worry about it.  After using KDE for over 20 years I have changed to LXDE
and LDDM.  I fully understand securing a application from noobs but hard wiring
"no root access" in the binary is just not right.  If you want your DE just for
noobs fine.  I'll just go with a DE that I can configure for my own needs.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2019-11-07 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #93 from Bo Weaver  ---
(In reply to Nate Graham from comment #86)
> I understand that you're frustrated. I'm frustrated too. If you have the
> appropriate technical skills, you could help to review
> https://phabricator.kde.org/D21795 and https://phabricator.kde.org/D21783?
> That's the path forward here.

I have checked both the links and I don't see any movement to fix this problem
and no discussion on my report.

When can I have my desktop back???  PLEASE! give me an ETA.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2019-10-27 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #91 from Bo Weaver  ---
Created attachment 123528
  --> https://bugs.kde.org/attachment.cgi?id=123528&action=edit
Security Report on the Functions of the KDE Desktop

(In reply to Nate Graham from comment #86)
> I understand that you're frustrated. I'm frustrated too. If you have the
> appropriate technical skills, you could help to review
> https://phabricator.kde.org/D21795 and https://phabricator.kde.org/D21783?
> That's the path forward here.

My technical skills are in internet security.  I have reviewed the two supplied
links and attached a report of my findings on the found security flaws.  Please
respect the fact I have done this for free in order to help the development
team in their security processes.  Normally I get paid for a report such as
this but in the spirit of open source this is free for anyone to use.

One question I have that needs to be urgently answered is when will access to
the root login be returned?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2019-10-27 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #89 from Bo Weaver  ---
(In reply to lega99 from comment #88)
> If I remember correctly, this is a Dolphin file manager.

Actually the Dolphin issue has been fixed.  The problem now is root login
though the GUI has been completely broken.  You cannot login as root with the
Plasma desktop.  If you install the MATE desktop Dolphin and Kate now still
work.

 I read big players
> plan to leave support for Plasma and KDE. In Kali update program plasma
> product dont work, synaptic work. I am no longer interested in constantly
> updating and constantly adding actions that I do not need, every new version
> uploads 200-300 files initially, and this is repeated all the time on
> verzion x,x 01 to x. x.5 .

Yes I can see Kali dropping support for KDE and SuSE is also not happy with
these changes since both distros depend on root logins.

> After that a new plsma version, new round of the same

To say this is to *secure* the system holds no value since a simple  
F1 gives you a tty which is root enabled.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2019-10-24 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #87 from Bo Weaver  ---
(In reply to Nate Graham from comment #86)
> I understand that you're frustrated. I'm frustrated too. If you have the
> appropriate technical skills, you could help to review
> https://phabricator.kde.org/D21795 and https://phabricator.kde.org/D21783?
> That's the path forward here.

I did look over the links.  I didn't see any discussion on locking root out of
logins or why this should be done.  I admit I'm not a coder I'm a security guy.
 I don't write applications or systems I break into them.  Last year I pointed
out many reasons that actions like this do nothing to secure the system.  Again
this does nothing to secure the system only break the DE.  Again CTL ATL F1
defeats your patch and will give you a root login.

Think about it hacks are normally done remotely through a system level service
or process.  A DE isn't the point of entry.  Crippling the DE does nothing to
keep an attacker out.  Even a local hack doesn't secure the system if an
account is compromised with sudo access so locking the root login does not to
secure the system.  Really you all are spending time and resources to fix a
problem that doesn't exist.

Really if you want to do something to really secure your DE then remove the
bubbleheads on the login screen with the user names and photos and blank all
the login fields.  Really this IS a security problem.

As I said before on with local access to the machine you have given me half the
problem of brute forcing an account, the user name.  Even more so with the
photo.  Let's say John has an account on a machine I could "guess" his user
name is john but what if his user name is "frogger" I could brute force john
unitl the end of time and get no where.  If I walk my his machine and see his
photo then I know his login is frogger so now I know what user name to brute
force.

Nate you said "That's the path forward here." do I need to login in there to
fight this battle?

PLEASE could I have my desktop back!

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2019-10-23 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #85 from Bo Weaver  ---
(In reply to Nate Graham from comment #84)
> *** Bug 413360 has been marked as a duplicate of this bug. ***

Well Nate here we are a year later having the same discussion.  I had a feeling
after updating my system when my root login failed it would lead back to this
exact same cause but I did have faith you all learned from last years mistake
and was hoping this wasn't going to be the exact same problem but here we are.

In security after something breached we have what is called a "Lessons Learned"
meeting to figure out what went wrong fix the problem and NEVER make the same
mistake twice.  Clearly this is not the case with developers.

You did last year after about 9 months fix dolphin and kate to work as normal
and I thank you for that.  You even included a nice warning message on dolphin
to be careful you are in root.  That was all that was needed.  A warning not a
lock out.

Again I to point out this work does NOTHING to secure the system a simple CTL
ATL F1 and you can get a tty and you can log in as root.  The only thing you
have accomplish is keeping me from getting any work done.

I want to point out something you could do to actually secure the system. 
These days it is hard to find a login screen that doesn't have bubbleheads with
the user names and photos on it or a login box that doesn't keep the last user
name in the login box.  Having all the users listed on the login screen gives
an attacked half the puzzle when brute forcing a password.  Plus it is real
ugly in an office where there are 15 users on a machine.  All them bubbleheads.
 One thing that helps secure Linux in a brute force password attack is you have
to know the user account name to run an attack.  Having the name and photo of
the user on the login screen gives you this information.  Even Windows gives
you a login screen with blank fields.

So when can I have my desktop back???

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-plasma] [Bug 413299] Login fails for root

2019-10-21 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=413299

--- Comment #2 from Bo Weaver  ---
(In reply to Kai Uwe Broulik from comment #1)
> Which main.qml?

/usr/share/sddm/themes/breeze-akey/Main.qml

After loading the file the error says "Cannot create children for parent that
is in a different thread.  Sorry I can't get all the text at the moment I am
sending this from another machine.

Even when changing the theme from something other than Breeze Akey I get the
same result no login with the root account except from MATE or tty.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-plasma] [Bug 413299] New: Login fails for root

2019-10-21 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=413299

Bug ID: 413299
   Summary: Login fails for root
   Product: frameworks-plasma
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: grave
  Priority: NOR
 Component: libplasmaquick
  Assignee: notm...@gmail.com
  Reporter: b...@boweaver.com
  Target Milestone: ---

SUMMARY

After running the latest updates when attempting to login to the Plasma desktop
using the root user the login appears to function and then goes back to the
login screen.  When a bad password is entered a proper bad password is shown. 
When logging in as a normal user the login functions fine.

STEPS TO REPRODUCE
1. Attempt to login as root from the desktop login.  Screen blinks and returns
to login screen
2. 
3. 

OBSERVED RESULT

Journalctl shows some problem with the QtQuick functions during the login
reading the main.uml during root login.  This doesn't happen with a normal user
account.

Changing to the MATE desktop root login works just fine and all applications
function fine.

tty logins as root work fine.

EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[Spectacle] [Bug 413057] New: Spectacle Crashes when taking a screen shot.

2019-10-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=413057

Bug ID: 413057
   Summary: Spectacle Crashes when taking a screen shot.
   Product: Spectacle
   Version: 19.08.1
  Platform: Debian testing
OS: Linux
Status: REPORTED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: General
  Assignee: m...@baloneygeek.com
  Reporter: b...@boweaver.com
CC: k...@david-redondo.de
  Target Milestone: ---

Application: spectacle (19.08.1)

Qt Version: 5.11.3
Frameworks Version: 5.62.0
Operating System: Linux 4.19.0-kali5-amd64 x86_64
Distribution: Kali GNU/Linux Rolling

-- Information about the crash:
- What I was doing when the application crashed:
I was taking a screen shot when either double clicking the area or hitting
enter to save the area the app crashes.

The crash can be reproduced sometimes.

-- Backtrace:
Application: Spectacle (spectacle), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f82e8bf7800 (LWP 10526))]

Thread 4 (Thread 0x7f82dfdf5700 (LWP 10529)):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x564872e5d8b8) at
../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x564872e5d868,
cond=0x564872e5d890) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x564872e5d890, mutex=0x564872e5d868) at
pthread_cond_wait.c:655
#3  0x7f82e437affb in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4  0x7f82e437ac17 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5  0x7f82ebeb2fb7 in start_thread (arg=) at
pthread_create.c:486
#6  0x7f82ed0cf2ef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f82e696f700 (LWP 10528)):
#0  __GI___libc_read (nbytes=16, buf=0x7f82e696eb50, fd=6) at
../sysdeps/unix/sysv/linux/read.c:26
#1  __GI___libc_read (fd=6, buf=0x7f82e696eb50, nbytes=16) at
../sysdeps/unix/sysv/linux/read.c:24
#2  0x7f82eb317cef in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f82eb2d0bee in g_main_context_check () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f82eb2d1042 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f82eb2d11bf in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x7f82ed62b393 in
QEventDispatcherGlib::processEvents(QFlags) ()
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7f82ed5d8d4b in
QEventLoop::exec(QFlags) () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f82ed428e36 in QThread::exec() () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f82ede0b545 in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5
#10 0x7f82ed432a27 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f82ebeb2fb7 in start_thread (arg=) at
pthread_create.c:486
#12 0x7f82ed0cf2ef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f82e8032700 (LWP 10527)):
#0  0x7f82ed0c4d2f in __GI___poll (fds=0x7f82e8031cb8, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f82eeb26cf7 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f82eeb2891a in xcb_wait_for_event () from
/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f82e87c3d79 in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7f82ed432a27 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f82ebeb2fb7 in start_thread (arg=) at
pthread_create.c:486
#6  0x7f82ed0cf2ef in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f82e8bf7800 (LWP 10526)):
[KCrash Handler]
#6  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#7  0x7f82ecffa535 in __GI_abort () at abort.c:79
#8  0x7f82ed050db8 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f82ed15baae "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#9  0x7f82ed05748a in malloc_printerr (str=str@entry=0x7f82ed159c22
"free(): invalid pointer") at malloc.c:5361
#10 0x7f82ed058bfc in _int_free (av=, p=,
have_lock=) at malloc.c:4187
#11 0x7f82ee7d88da in ?? () from
/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5
#12 0x7f82ee7d8ab3 in ?? () from
/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5
#13 0x7f82eead2d3a in ?? () from /lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#14 0x7f82eead361e in ?? () from /lib/x86_64-linux-gnu/libKF5XmlGui.so.5
#15 0x7f82ed6035d3 in QMetaObject::activate(QObject*, int, int, void**) ()
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7f82ed60f017 in QTimer::timeout(QTimer::QPrivateSignal) () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f82ed603ccb in QObject::event(QEvent*) () from
/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x7f82ee11d501 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x7f82ee1249b0 in QAppl

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-08-21 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #72 from Bo Weaver  ---
(In reply to Nate Graham from comment #71)
> Bo, the version of all KDE apps should be the same. So for example if you're
> using Gwenview 18.08, then you're also using Dolphin 18.08. So you can check
> your Gwenview version to find out what version of Dolphin you have, even if
> Dolphin won't run when you're logged in as the root user.

Gwenview says 18.04 so Kali hasn't upgraded to .08 yet.

> 
> Alexander was trying to use sudo, not log in as root. Logging in as the root
> user should be fixed now in 18.08. If you can confirm that you're running
> Dolphin 18.08 and it still doesn't work when you *log in as the root user*
> (not using sudo), then there's still a bug and I'll try my best to fix it.
> 
> We are all trying our best to fix the issue here. Please be respectful.
> Insults and abuse don't make friends or fix problems.

Nate as I have said before I would rather have a respectful conversation but
when told one thing and my eyes see another I do call BS.  As I have said
respect has to work *both ways*.

> We are all trying our best to fix the issue here.

We're talking about removing less than two lines of code that should not have
been there in the first place.  We're not talking some complex application that
has to be completely taken apart to fix.  Really you don't have to remove any
code just roll it back to the original that worked.  I'm not sure what
versioning software you use but all of them have them ability to do a roll
back.

About respect, I asked you a direct question that you did not address.  Where
are the links I ask for on where to find the older binaries?  Can't I just copy
them over to my machine?  It's respectful to give an answer when asked a
question.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-08-21 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #70 from Bo Weaver  ---
First I'd like to point out that this was submitted as a single bug report. 
YOU GUYS merged it into the bug so sorry Nate if you don't like us writing to
this bug.  You all put it here.

I did update my system and no joy on the update to these applications.  I do
know that since you all broke root I can't even see what version of dolphin or
kate is running they error out "can't run as root".  So finding out exactly
what version is now running is impossible --version is broken.

You say there is only 3 bug fixes a version well explain this.  There were some
major updates happened to KDE during the update.  I always see something on KDE
get updated on every update which I do a lot.  So if there are only 3 then
where do all the "other" updates come from if not from you all?  The update
fairy???

Also note from Alexander's comment:
Plasma: 5.13.80
Apps: 18.11.70

I know developer's don't know math very well but .8 and .7 is GREATER THAN .3 
Yes engineers can do math.  So your comment about only 3 changes per release is
either an out right lie or you guys don't know anything about versioning.

Even with that this is more than a simple bug.  You went way beyond your bounds
as DE developers and BROKE root access to applications.  You broke OS access. 
There are rules to OS development and you all broke them knowingly and
willingly.

What really makes me mad is you all have yet to admit this was a serious
mistake made by you all and reply to us like we don't know what we are talking
about and refuse to quickly fix your screw up.  It is especially bad when the
fix is just upload the old binaries to the repos.

At the very least you could give us some links to where the old binaries are at
so we could download them and manually install them.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-08-20 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #67 from Bo Weaver  ---
Nate,

I'd like to point out again.  This has nothing really to do with "sudo" access.
 It is that KDE has crippled "root" access.  I know you have said that this
will be fixed in the next version BUT it has been over 8 months now and not
fixed.  I did notify Kali but it appears they are not going to backport kate
and dolphin.  This is just a couple of lines of code you all included so
PLEASE!! just take it out and you all do the backporting.  After all this is
KDE's mistake in the first place.  It would seem you all would do the "right
thing" and get this fixed now not later.

Please understand some of us make our living using your tools we aren't playing
we have real work to do and this cripples our jobs.  I bet you wouldn't like
working with a broken IDE for 8 months.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-06-25 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #58 from Bo Weaver  ---
Nate

I was wondering when this might be pushed out.  I have seen that kate and
dolphin have both updated twice on Kali but the function has not returned to
the applications.

I'm working on a book about Kali and I'm kinda stuck on the KDE section until
this is fixed.  I would like to include the normal functions of kate and
dolphin and not include the workarounds to get around this bug.  I really want
to give KDE the best review possible.

Thanks
Bo



(In reply to Nate Graham from comment #56)
> Somehow this bug about PolicyKit integration in KIO got sidetracked into a
> discussion about whether you should be able to use Dolphin and Kate while
> logged in as the root user. I'm happy to report that a patch I submitted to
> let you do just that was accepted, and the functionality has been restored. 
> See Bug 387974 and Bug 387973. Dolphin and Kate should once again be fully
> functional in Kali et al.
> 
> Hopefully now this ticket can return to tracking PolicyKit integration for
> KIO. That will be implemented once https://phabricator.kde.org/D7571 lands,
> which is currently blocked by outstanding security issues that were
> discovered in an audit: https://phabricator.kde.org/T8075.
> 
> We're getting really close!

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-06-08 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #57 from Bo Weaver  ---
(In reply to Nate Graham from comment #56)
> Somehow this bug about PolicyKit integration in KIO got sidetracked into a
> discussion about whether you should be able to use Dolphin and Kate while
> logged in as the root user. I'm happy to report that a patch I submitted to
> let you do just that was accepted, and the functionality has been restored. 
> See Bug 387974 and Bug 387973. Dolphin and Kate should once again be fully
> functional in Kali et al.
> 
> Hopefully now this ticket can return to tracking PolicyKit integration for
> KIO. That will be implemented once https://phabricator.kde.org/D7571 lands,
> which is currently blocked by outstanding security issues that were
> discovered in an audit: https://phabricator.kde.org/T8075.
> 
> We're getting really close!

Dear Nate,

I want to thank you for getting this fixed.  I this has renewed by faith in
KDE.  The patch hasn't made it to Kali yet but I'm sure it will be soon.  I
really didn't want to change desktops after 25 years of use.  

Bo Weaver

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-04-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #54 from Bo Weaver  ---
(In reply to Bo Weaver from comment #53)
> (In reply to Antonio Rojas from comment #51)
> > (In reply to Bo Weaver from comment #50)
> > > Created attachment 112015 [details]
> > > Screen Shot
> > > 
> > > When using kate from the CL you get this in the error.
> > > 
> > > "Executing Kate as root is not possible. To edit files as root use:
> > > SUDO_EDITOR=kate sudoedit "
> > > 
> > > In many of the blogs it says to use this method.  The method doesn't 
> > > work. 
> > > Please see attached screen shot as evidence.
> > 
> > You are *still* trying to run it as root. You're supposed to do that as a
> > regular user. But in any case, that is obsolete, with a recent enough
> > ktexteditor you can edit root owned files by running kate as a regular user.
> 
> Dear Antonio Rojas
> 
> Clearly you didn't *read* my other posts.  You also didn't read my posts on
> the kate flaw thread either.  Of course I am *still* looged in as root. 
> There are use cases where you *must* be logged in as root to preform your
> work properly.  Pen Testing is one of these cases.  As a security
> researcher, pen tester, Assessor, and Security Analyst for almost 30 years. 
> I must ask "How do you test your code???"  Do you only use autmomated
> testing.  Clearly you do use the defacto industry standard disto (Kali) for
> pen testing to do manual testing of your code or you would understand the
> need for root access to applications.  If you are not manually testing your
> code with the manual tools used on a daily basis by hackers then this is a
> greater security risk than having Kate of Dolphin running as root.  This is
> an EPIC FAIL on your part.  Please remember Mr. Coder I do this for a
> living.  You have failed your assessment.  Your reply has just shown KDE
> developers are not properly manually auditing their code.
> 
> Let's talk about the attachment I sent in.  The error says use SUDO_EDITOR. 
> Well what if sudo is set up to be run with NO PASSWORD if an attacker gains
> access to the system under a normal user with sudo rights then this command
> can be ran and root access gained through the embeded Konsole without the
> use of a PASSWORD!  AWS systems the ubuntu account is set up in this manner.
> So your work around is more dangerous than what you are attempting to fix. 
> So you have "fixed" nothing only broken the application from normal use.
> 
> I hate to repost but since you didn't read my reply on the other thread here
> it is again.
> 
> Here's a BIG technical reason for this to be changed back.
> 
> Root is a "system level" account not a user account under control of the OS
> and not the desktop.  Root is to have full access to every process and
> application.  This has been a UNIX standard since the 1970's.  KDE is NOT a
> system level process.  KDE is a desktop which runs in the Presentation and
> Application of the OSI model (You guys have heard of the 7 layers of the OSI
> model?)  The root account is part of the System layer of this model.  When
> developing and application the developer is not to screw with the system
> functions.  These embedded flaws do just that by breaking root access to
> these bineries. 
> 
> Here's a suggestion...  Why don't developers take some courses in Linux
> Systems Engineering and learn the rules and standards that the operating
> systems are built by?  Clearly you all are not engineers or this would not
> be a problem and I would not be writing all this.  Take time to learn the
> OSI model that operating systems are designed by. 
> 
> One reason I was told for this change was Wayland now runs in the user
> space.  Yes this is the case when logged in under a normal user account the
> compositor runs under that account.  When logged in under a root account
> this is not the case the compositor then runs under the root account just
> fine.  Download a copy of Kali the the Gnome DE and you'll see Wayland does
> run under root when you are root.  So this reason is flawed.
> 
> I have yet to get a reply on any of this from you all.
> 
> Again I am the guy you are attempting to "keep out" of your processes and
> again I will say this.  If I have hacked a box and have a normal users
> access I am not going to attempt to hack a running kate of dolphin process
> running under root because THIS PROCESS CAN BE KILLED AT ANYTIME BY THE
> PERSON RUNNING THE PROCESS!  I will attempt to hijack a running SYSTEM
> PROCESS not a user application.
> 
> And again I write this below.  so

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-04-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #53 from Bo Weaver  ---
(In reply to Antonio Rojas from comment #51)
> (In reply to Bo Weaver from comment #50)
> > Created attachment 112015 [details]
> > Screen Shot
> > 
> > When using kate from the CL you get this in the error.
> > 
> > "Executing Kate as root is not possible. To edit files as root use:
> > SUDO_EDITOR=kate sudoedit "
> > 
> > In many of the blogs it says to use this method.  The method doesn't work. 
> > Please see attached screen shot as evidence.
> 
> You are *still* trying to run it as root. You're supposed to do that as a
> regular user. But in any case, that is obsolete, with a recent enough
> ktexteditor you can edit root owned files by running kate as a regular user.

Dear Antonio Rojas

Clearly you didn't *read* my other posts.  You also didn't read my posts on the
kate flaw thread either.  Of course I am *still* looged in as root.  There are
use cases where you *must* be logged in as root to preform your work properly. 
Pen Testing is one of these cases.  As a security researcher, pen tester,
Assessor, and Security Analyst for almost 30 years.  I must ask "How do you
test your code???"  Do you only use autmomated testing.  Clearly you do use the
defacto industry standard disto (Kali) for pen testing to do manual testing of
your code or you would understand the need for root access to applications.  If
you are not manually testing your code with the manual tools used on a daily
basis by hackers then this is a greater security risk than having Kate of
Dolphin running as root.  This is an EPIC FAIL on your part.  Please remember
Mr. Coder I do this for a living.  You have failed your assessment.  Your reply
has just shown KDE developers are not properly manually auditing their code.

Let's talk about the attachment I sent in.  The error says use SUDO_EDITOR. 
Well what if sudo is set up to be run with NO PASSWORD if an attacker gains
access to the system under a normal user with sudo rights then this command can
be ran and root access gained through the embeded Konsole without the use of a
PASSWORD!  AWS systems the ubuntu account is set up in this manner.  So your
work around is more dangerous than what you are attempting to fix.  So you have
"fixed" nothing only broken the application from normal use.

I hate to repost but since you didn't read my reply on the other thread here it
is again.

Here's a BIG technical reason for this to be changed back.

Root is a "system level" account not a user account under control of the OS and
not the desktop.  Root is to have full access to every process and application.
 This has been a UNIX standard since the 1970's.  KDE is NOT a system level
process.  KDE is a desktop which runs in the Presentation and Application of
the OSI model (You guys have heard of the 7 layers of the OSI model?)  The root
account is part of the System layer of this model.  When developing and
application the developer is not to screw with the system functions.  These
embedded flaws do just that by breaking root access to these bineries. 

Here's a suggestion...  Why don't developers take some courses in Linux Systems
Engineering and learn the rules and standards that the operating systems are
built by?  Clearly you all are not engineers or this would not be a problem and
I would not be writing all this.  Take time to learn the OSI model that
operating systems are designed by. 

One reason I was told for this change was Wayland now runs in the user space. 
Yes this is the case when logged in under a normal user account the compositor
runs under that account.  When logged in under a root account this is not the
case the compositor then runs under the root account just fine.  Download a
copy of Kali the the Gnome DE and you'll see Wayland does run under root when
you are root.  So this reason is flawed.

I have yet to get a reply on any of this from you all.

Again I am the guy you are attempting to "keep out" of your processes and again
I will say this.  If I have hacked a box and have a normal users access I am
not going to attempt to hack a running kate of dolphin process running under
root because THIS PROCESS CAN BE KILLED AT ANYTIME BY THE PERSON RUNNING THE
PROCESS!  I will attempt to hijack a running SYSTEM PROCESS not a user
application.

And again I write this below.  sorry to keep repeating myself but you all don't
seem to be listening.

People like myself that must be logged in as root for work understand the risk
and are careful and parinod while in root.  They also understand the risk and
if anything bad happens they assume the risk.  As people like myself only work
under the root account to only do the work needed and then change to a normal
user account for normal use.  I don't need you to hold my hand a

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-04-13 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #50 from Bo Weaver  ---
Created attachment 112015
  --> https://bugs.kde.org/attachment.cgi?id=112015&action=edit
Screen Shot

When using kate from the CL you get this in the error.

"Executing Kate as root is not possible. To edit files as root use:
SUDO_EDITOR=kate sudoedit "

In many of the blogs it says to use this method.  The method doesn't work. 
Please see attached screen shot as evidence.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-03-04 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #45 from Bo Weaver  ---

Is this going to be fixed soon?  At one time I did find a configuration file
the the line "if uid=0 fail"  I didn't write down the location or file name and
now I can't find it I am wondering if I jack up the uid number will uid 0 stop
failing.

Just PLEASE!!! tell a way I can fix it back

BTW as someone that hacks systems of a living even when running under a normal
account you have a lot of kworker process running as root if a Kate or Dolphin
process running as root can be hijacked then the kworker process is also most
likely vulnerable.  Again breaking kate and dolphin has secured nothing.

Again you have only created a problem not fixed one.

Again by design root is to have full access to everything.  Root is NOT a
restricted account.  This is a UNIX/Linux thing not a desktop thing.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 152150] Cannot 'Open as Root' files/directories

2018-02-24 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=152150

--- Comment #14 from Bo Weaver  ---
First let me correct your English.  “Resolved” is not the right word to be
using.  This problem has NOT been resolved.  OK it is also marked “WONTFIX”
this is fine since your arrogance has spoken and you feel you have the right to
restrict to use of applications that someone wants to use as they see fit. 
What happened to the term “Open System”??

I am totally appalled of the fact that you cut out threads in the bug report
posted by me and others saying this is a bad idea and doesn’t secure a thing. 
This is an open forum you know the “free exchange of ideas”.  This was only
done in order for you the developers to not look bad and not look stupid. 
Still sweeping things under the rug doesn’t make things right.  It just shows
your integrity as a Human Being.

There are work arounds around your broken applications Leafpad works just fine.
 Sure it doesn’t have the features and functions Kate does.  It isn’t as pretty
but… IT WORKS!  I just loaded PcmanFM file manager and it works great it even
has some nice functions that Dolphin doesn’t have, and IT WORKS!  This will
keep me making a living until I can move my work machine over to LXDE.

The sad thing is after over 20 years of using KDE and loving it I am now in the
process of moving over to LXDE.  After doing some research the LXDE group seem
to have a better understanding of the term “Open Systems”.  No it isn’t as nice
and isn’t as polished but everything works.  

As a Pen Tester normally on a Linux machine when I try to hijack a root process
I go for more of a system process and not Kate or Dolphin processes running as
root.  A system process is less likely to be killed while compromising the
machine where Kate running as root can be killed at any time by the user when
they complete whatever task they are doing with Kate.  Rest assured from this
day forward when I’m in a Linux box looking for a running root process to
hijack I will go for all those root processes that start with a “K” just to
prove you have secured NOTHING by your actions.  Just made your product
unusable.

BTW Did you all work for Microsoft in the past?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-01-22 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #44 from Bo Weaver  ---
(In reply to Bo Weaver from comment #41)
> (In reply to Nate Graham from comment #39)
> > Thanks for working with me and digging deep here. In the end, this was all
> > just a big misunderstanding, not some kind of conspiracy. :) 
> > 
> > Bugs for Dolphin and Kate:
> > - https://bugs.kde.org/show_bug.cgi?id=387974
> > - https://bugs.kde.org/show_bug.cgi?id=387973
> > 
> > Are there any other apps that gained PolKit support but stopped launching
> > when you're logged in as the root user?

I don't know if you saw my last email but after the last round of updates now
Konqueror fails to work when logged in under root.  Question is Krusader next
to stop working???  Everything I have tested using a normal account and
modifying files or changing configurations the KIO and policy-kit are working
fine.  You get a proper password box before the file is saved.  When logged in
under the root account more is dying we are going in the wrong direction. 
Again killing access to Kate and other tools accomplishes nothing since other
applications that preform the same task work fine and will continue to work
since they are not your tools and you can't modify their code.  Kate may not
work but Leafpad, Nano, Vi, and Emacs just to name a few work fine.

Wayland was blamed for part of this and I was told Wayland is planning on
killing GUI logins under the root account.  I could find anything on this in
the Wayland forums.

You said this is not some kind of conspiracy but killing Konqueror in the last
round of updates does make it appear that something is going on that isn't
right.

I sill haven't gotten an answer to why Gmone, MATE, and other DEs aren't
following this path it is only KDE killing root.  Why?  Especially when the
biggest disto that uses you desktop by default fixes your builtin bug.

If I am talking to the wind here please just tell me to just f_ck off and die
and this 20 year user of your desktop will sadly change to MATE.  I need to
know something this killing applications without reason is screwing with the me
making a living.  Its no fun to sit down ready to work and find out that the
tools you used yesterday no longer work because you updated the system.  This
is especially maddening when you work in security and you know for a fact this
all fixes nothing and secures nothing within the DE or the OS.  It just makes
the DE useless for some use cases.

> 
> I just tried some more applications.  All "custom" applications for Kali
> appear to be working fine.  The PIM interface did load.  I don't use it
> under root so it wasn't fully configured but did properly go into the set
> up.  The only applications I have found that don't work is Dolphin, Kate and
> Kwrite.  From the command line these all fail with the can't run under root
> error.  From the desktop when the icon is clicked they just fail no errors. 
> This is only happening when logged in the desktop as root.  When I am in a
> normal user account Kate runs and when saving a system file I get a proper
> password prompt.  This also happens when copying a file to a system
> directory.
> 
> Please don't get me wrong guys this is the "right way" for normal users the
> root account locked out and a password protected way to change files from a
> user account.
> 
> I just really miss Kate for me it is the finest text editor ever made.
> 
> Thanks for your all's help getting this fixed up

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2018-01-10 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #43 from Bo Weaver  ---

>From earlier replies I thought you all were going to fix this problem but after
updating my system it seems you all just have made the problem worse.  The
problem was Kate and Dolpin not working when logged IN as root.  Now Konqueror
has now stopped working when logged IN as root.  AGAIN some people must work
with a full root login.  I know you all say Wayland will not support root
logins but it is up to you the developer to deal with them and explain this is
a stupid idea. Some people must work under root.  Again guys you are breaking
the operating system and it is not up to you or the Wayland guys to screw with
the underlying OS.  Root is root and root has full access to EVERYTHING.  What
part of everything do you not understand.  Again you are screwing with how I
make my living by screwing with something you have no right to mess with.  Root
access.  

Think about this Suse and others are pushing out patches to remove your work. 
Doesn't this tell you this isn't what the customer wants?  I know you say you
are trying to make Linux idiot proof but take a good look most users of KDE are
advanced user which know and assume responsibility of running root. 

Guys like I said I have used KDE since the 90's and sure I've had quirks but I
have never seen you all mess with parts of the OS you weren't suppose to.  I
really hate to have to rebuild my work machine to use MATE or something and
trashing KDE.

PLEASE REMOVE this blocking of UID=0 from your applications.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2017-12-17 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #42 from Bo Weaver  ---
(In reply to Pawel from comment #40)
> I'm following this issue keenly, would be greatly interested in seeing this
> solved. By the way Bo, you don't have to go back as far as Midnight
> Commander; Krusader works just fine in root mode.

Thanks again guys for getting this fixed.  Some people like me have to work
under root.  I never tell an average user that and only when I'm testing do I
run under root.  I right now I am typing this from a locked down luser account.

Like I said earlier you all are going the right direction with security for the
average Joe.  I have two machines also here (yes they run KDE) that root have
never been unlocked and never will be.  They're just puters.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2017-12-17 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #41 from Bo Weaver  ---
(In reply to Nate Graham from comment #39)
> Thanks for working with me and digging deep here. In the end, this was all
> just a big misunderstanding, not some kind of conspiracy. :) 
> 
> Bugs for Dolphin and Kate:
> - https://bugs.kde.org/show_bug.cgi?id=387974
> - https://bugs.kde.org/show_bug.cgi?id=387973
> 
> Are there any other apps that gained PolKit support but stopped launching
> when you're logged in as the root user?

I just tried some more applications.  All "custom" applications for Kali appear
to be working fine.  The PIM interface did load.  I don't use it under root so
it wasn't fully configured but did properly go into the set up.  The only
applications I have found that don't work is Dolphin, Kate and Kwrite.  From
the command line these all fail with the can't run under root error.  From the
desktop when the icon is clicked they just fail no errors.  This is only
happening when logged in the desktop as root.  When I am in a normal user
account Kate runs and when saving a system file I get a proper password prompt.
 This also happens when copying a file to a system directory.

Please don't get me wrong guys this is the "right way" for normal users the
root account locked out and a password protected way to change files from a
user account.

I just really miss Kate for me it is the finest text editor ever made.

Thanks for your all's help getting this fixed up

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2017-12-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #38 from Bo Weaver  ---
(In reply to Bo Weaver from comment #37)
> (In reply to Nate Graham from comment #36)
> > Let me make sure I understand:
> > 
> > - With GNOME, you log in as the root user with a Wayland session OR an X
> > session and in both cases you can run Gedit and Dolphin as the root user
> 
> Yep with Gnome running a X session Gedit and their File Manager (Natulius)
> (Spelled wrong)  work just fine when logged in as root.  By default Kali is
> set up with only a root account.
> 
> > 
> > - With KDE Plasma, you log in as the root user with a Wayland session OR an
> > X session and in both cases you can't run Kate or Dolphin
> 
> Yep they just "don't work" no error no nothing.  Since I am an advance user
> I did know to run the executable from the command line and then got the
> error can't run as root.  Breaks your heart when you click on Dolphin like
> you have 10,000 times and after an update nothing happens.
> 
> Even in KDE when logged in as root LeafPad and Gedit will open an run and
> change files just fine.  This is my point you haven't stopped editing files
> you've only stopped me from using Kate.  Midnight Commander also works just
> fine.  I just don't like going back to 1980.  
> 
> Yep just checked Gnome on both Wayland and Xorg the default text editors and
> file manager work fine when logged in as root.  This is a KDE problem.
> 
> > 
> > If that is the case, then I think we have found the actual bug and I agree
> > that it should be fixed. This ticket just tracks general Polkit adoption, so
> > we should track that issue with a new bug report.
> 
> Thank you!  yes this is a bug.  When logged in as root there should be no
> restrictions on anything.  That's the reason for the root account.  Now days
> this account is locked and rightly so.  Really Polkit from what I have read
> is for system changes from a normal user account like of like sudo to
> elevate privileges for a single action (good thing)  Such as changing a
> configuration file.  I'm all for this.  What I am saying is when an advanced
> user enables the root account and logs in there should be no restrictions on
> anything.  You guys are in control of the desktop not the underlying OS. 
> The PolicyKit should have no control when logged in as root.  Your root.
> 
> If you want to restrict Kate and Dolphin from a normal user account go right
> ahead but leave the root account alone.


BTW I just tried Kate and Dolphin from a normal user account on a Kali machine.
 When I went to edit a system file it did give me a proper password prompt. 
Kate worked just fine in this manner.  It appears this problem is when only
logged in as root.  This is fine from the normal user account.  Kate won't fire
at all from root.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2017-12-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #37 from Bo Weaver  ---
(In reply to Nate Graham from comment #36)
> Let me make sure I understand:
> 
> - With GNOME, you log in as the root user with a Wayland session OR an X
> session and in both cases you can run Gedit and Dolphin as the root user

Yep with Gnome running a X session Gedit and their File Manager (Natulius)
(Spelled wrong)  work just fine when logged in as root.  By default Kali is set
up with only a root account.

> 
> - With KDE Plasma, you log in as the root user with a Wayland session OR an
> X session and in both cases you can't run Kate or Dolphin

Yep they just "don't work" no error no nothing.  Since I am an advance user I
did know to run the executable from the command line and then got the error
can't run as root.  Breaks your heart when you click on Dolphin like you have
10,000 times and after an update nothing happens.

Even in KDE when logged in as root LeafPad and Gedit will open an run and
change files just fine.  This is my point you haven't stopped editing files
you've only stopped me from using Kate.  Midnight Commander also works just
fine.  I just don't like going back to 1980.  

Yep just checked Gnome on both Wayland and Xorg the default text editors and
file manager work fine when logged in as root.  This is a KDE problem.

> 
> If that is the case, then I think we have found the actual bug and I agree
> that it should be fixed. This ticket just tracks general Polkit adoption, so
> we should track that issue with a new bug report.

Thank you!  yes this is a bug.  When logged in as root there should be no
restrictions on anything.  That's the reason for the root account.  Now days
this account is locked and rightly so.  Really Polkit from what I have read is
for system changes from a normal user account like of like sudo to elevate
privileges for a single action (good thing)  Such as changing a configuration
file.  I'm all for this.  What I am saying is when an advanced user enables the
root account and logs in there should be no restrictions on anything.  You guys
are in control of the desktop not the underlying OS.  The PolicyKit should have
no control when logged in as root.  Your root.

If you want to restrict Kate and Dolphin from a normal user account go right
ahead but leave the root account alone.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 387950] Dolphin no longer works under root

2017-12-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=387950

--- Comment #2 from Bo Weaver  ---
(In reply to Elvis Angelaccio from comment #1)
> (In reply to Bo Weaver from comment #0)
> > Today I updated my system and found that Dolphin and Kate no longer run
> > under root.  I look and saw that this is considered a security issue.  As a
> > Pen Tester I run under root during testing.  I do understand that normally
> > you would never run under root.  When you logged in as root then why is it a
> > problem accessing files with dolphin?  If the problem is these is a security
> > hole from a normal user account because root can access files with Dolphin
> > then fix the problem don't just break it and turn it off this doesn't "fix"
> > anything.
> 
> No, the problem is that Xorg is not secure. See
> https://cgit.kde.org/kate.git/commit/
> ?id=9adcebd3c2e476c8a32e9b455cc99f46b0e12a7e
> 

I did check out the link and according to the link the problem is "simple bugs
in either kate/kwrite itself or in the underlying libraries such as Qt, XLib or
xcb."  Wouldn't the correct path be fix the bugs in the underlying libraries
not just kill the application?  If these are shared libraries then they could
be also exploited when say the Systems Manager is opened or the Update Manager
is ran.  Killing Kate wouldn't fix an issue with shared libraries.



> 
> > Dear developers people need to access system files from time to time and
> > change those files.  
> 
> Kate already prompts for the root password whenever you edit a system file.
> Dolphin will soon, hopefully.

I don't "see" a prompt I can't open a file.  Kate just doesn't run at all. 
Only when starting kate from the command line am I given an error response.

You missed my point.  I am logged in as root.  Everything I'm doing is
dangerous.  I know this an assume all responsibility for this.  I need this
function for my job.  Just killing access to Kate and Dolphin will not protect
anything when logged in as root.  I'm not talking about sudo or running Kate
"as root" from a users account.  The only thing that is accomplished is I have
to LeafPad to edit a file.  Kate has been my favorite text editor for years.

I do understand that on most machines the root account is and should be locked
by default.  When I set up a Linux box for a normal person I leave it this way
your right they don't need full access in the same manner I do.  Still they're
are some of us that need that level of access and are advanced enough to use a
system in that mode and are willing to assume responsibility for any actions
taking my the themselves.  If your application is not secure enough to be run
by a root user it should not even be on the system.

Basically you're saying don't run KDE on Kali Linux.  Is this right?

> 
> *** This bug has been marked as a duplicate of bug 152150 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2017-12-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

--- Comment #35 from Bo Weaver  ---
(In reply to Nate Graham from comment #34)
Thanks for the reply Nate.  Your reply does answer some questions and your
reply is more open to discussion instead of just WONTFIX.  thank you.

> Bo, you're not really arguing against a decision made here, but rather
> against the whole direction that our industry is going in. As has been
> mentioned, Wayland disallows running GUI apps as root. As a penetration
> tester, this may make your life more difficult, but you're not the user that
> the Wayland folks are targeting. 

I didn't know that about Wayland.  True I don't stay on top of desktop coding
I'm a pen tester I just "use" the desktop.  You are right for pen testing I
guess this means going back to 1970 and not even install a desktop.

Yes the way the industry it appears is everything will be a phone one day. 
What about those of us that need a REAL computing system?  We're not all
lusers.  I don't even own a smart phone for this reason.

> They are trying to make computers more
> secure for ordinary users (who have difficulty with the concepts we're
> discussing), not more convenient for security researchers. I would recommend
> you take your case to the Wayland folks, though I doubt you'll get very far
> because this is an architectural design decision that doesn't really seem
> open for debate.

I know that is the party line about ordinary users, but this isn't the case I
have seen in the "real world".  I have a lot of friends that now use Linux
because of me.  Normal people truck drivers, Ironworkers, 83 year old
Grandmothers.  People you have no clue on how it all works and they don't care
they use want it to work and it works fine for them.  They never need to go
into root.  Lately most distros the root account is locked its there but locked
and can be easily unlocked if needed.  This works fine and is secure.  When
sometime breaks they call me and I do the root work.

I know what you are saying about the Wayland team is true from what I have
followed about Wayland on the net they do have their head up their a_s and it
is their way of the highway.  Much like systemd got crammed down our throats. 
At least they didn't cut out root access to systemd.  

This is the real problem here developers are always trying to fix non-problems
and think they know better than the actual users.  Gnome totally destroyed
their desktop with thinking like this.  I wonder how any developers on this
team use Macs or other systems to write code everyday?  Does everyone use KDE
for their day to day computing?  I do.

Question here:  Gnome runs on Wayland yet their file manager and text editor
work just fine with the desktop running under root.  Kali's default desktop is
Gnome and Kali is set up to run under root.  So why not KDE?

> 
> Instead, you're in the same boat we are: given that currently (or in the
> near future), we won't be able to open GUI apps as root, how can we avoid
> losing existing functionality? So far the answer seems to be PolKit
> adoption, which lets you open apps using normal user permissions and only
> request elevated permissions when necessary. Again this isn't really our
> decision; the world evolves and we need to evolve along with it or else our
> software will stop working.
> 
> > Well it seems that you all screwing with KIO broke kate so why report it to 
> > the
> > kate team?  BTW what you said about opening a root owned file is wrong.  
> > Kate
> > will not open AT ALL under root.  you said I can see the file how?? Kate 
> > won't
> > even open.  It doesn't "work like a charm" it doesn't work AT ALL.
> 
> You don't open Kate as root anymore. You open it with normal permissions and
> edit your root-owned file, either by opening it with the File > Open dialog,
> or via `kate /path/to/root/owned/file.txt`. When you save, you should get
> prompted for credentials to complete the save operation.

I'm running IN root.  3 days ago Kate worked just fine under root after an
update 2 days ago it will not open at all.  I'm not attempting a sudo action. 
I am root.

> 
> Both of those use cases work for me with KDE Frameworks 5.40 and Kate 17.12,
> and they have worked for quite a while. If either of those use cases do not
> work for you, please let us know.

No this doesn't work and this does breaks the consecpt of root access.  Root is
to have FULL access to everything.  This means a file manager or a text editor
or any other application or process.

In engineering we have a saying "If it ain't broke don't f_ck with it".  I
think you developers should take heed to that.

A security note here.  as someone who hacks Li

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

2017-12-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=179678

Bo Weaver  changed:

   What|Removed |Added

 CC||b...@boweaver.com

--- Comment #33 from Bo Weaver  ---
(In reply to Nate Graham from comment #25)
> Nobody is dumbing anything down. 
Yes you are.  I know when I am in root I know the dangers.  I don't need you
killing applications to make me safe.  Did you all forget the meaning of "root"
in Linux?  Actually you are screwing with access to something out of your
control.  Root is a system function not a desktop function.

> Basic security involves running with the
> lowest permissions possible. That's why you selectively use sudo when you
> need to edit something as root, rather than using into the root account 100%
> of the time. This is simply a further extension of the principle: run with
> normal permissions until the software requests an action demanding elevated
> permissions, and only then do we ask for those permissions.

Actually there are Use Cases that a user must run under root 100% such as Pen
Testing.  When pen testing you need full access to your OS.  OK you say use
sudo yet "sudo kate" doesn't work.  Yet when in root Gedit, nano, LeafPad Vi
and Emacs all run under root so explain how have you so called "protected" file
access??


> 
> If some part of the new system doesn't work properly, that's a bug, and we
> should--and will--fix it. 

Well it broken SO fix it!

> But note that this particular bug report concerns
> KIO, not Kate. Anyone who's having an issue with Kate should file a new bug
> against the Kate product. And FWIW, Kate's PolKit support has been working
> just fine for me. You can open a root-owned file and then only when you save
> it are you prompted for credentials. Works like a charm, no "dumbing down"
> involved.

Well it seems that you all screwing with KIO broke kate so why report it to the
kate team?  BTW what you said about opening a root owned file is wrong.  Kate
will not open AT ALL under root.  you said I can see the file how?? Kate won't
even open.  It doesn't "work like a charm" it doesn't work AT ALL.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 152150] Cannot 'Open as Root' files/directories

2017-12-16 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=152150

--- Comment #12 from Bo Weaver  ---
So this is a WONTFIX.  This is the first time in over 20 years I have seen KDE
get stupid.  So it is dangerous to open system files and to edit system files
and "I" might make a mistake.  Dude I have been using Linux since the 1990's
sure I've done some stupid things and have borked my system doing stupid
things.  Did I blame it on you?  Of course not.  My fault.  What you are doing
is removing my control of MY operating system.  You are cutting off my control
of the OS.  Your a desktop and this really shouldn't be your decision.  In
other posts is was said that you are going the way of Gnome which you are.  At
one time Gnome was a nice desktop but due to self-center developers it is the
Windows 8.1 desktop for Linux and totally unable with more than two monitors. 
Seems you guys have went down the same trail.

I have work in systems/network security for over 20 years and let me tell you
your reasons are WRONG.  Sure logged in as root is dangerous but at times a
person must have access to the system killing access doesn't fix anything.  You
guys are developers and you are not security engineers.  Even with this broken
fix there are still methods to drop to root if you are hacking the system.  You
haven't "fixed" anything. you have only broken access.

You even say a text editor is dangerous. WTF!! Oh you might break your system
with Kate yet Gedit, LeafPad, Nano, Vi and Emacs ALL work under root.  So
killing access of Kate doesn't keep a person from Editing or changing files. 
YOU HAVEN"T "FIXED" ANYTHING.

I can access and delete system files from the command line what next breaking
access to system files from Konsole?  What's next when I run "ls /etc" in
Konsole will I soon get an error "Your too stupid to see these files"

One thing I have always like about KDE is it is highly configurable.  You can
change just about anything with the desktop except of now.

I guess after 20 years of use I'll just find something else to use.  Sad...  I
know you all write the code but you are not God and you clearly don't
understand to use case of users.

I read one article that this is for "Joe User" I hate to tell you this but Joe
Luser doesn't use KDE the more advanced user uses KDE or did and advanced users
want access to the friggin system.

Hell even Windows will give you access to the OS when needed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 387950] New: Dolphin no longer works under root

2017-12-15 Thread Bo Weaver
https://bugs.kde.org/show_bug.cgi?id=387950

Bug ID: 387950
   Summary: Dolphin no longer works under root
   Product: dolphin
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: dolphin-bugs-n...@kde.org
  Reporter: b...@boweaver.com
CC: elvis.angelac...@kde.org
  Target Milestone: ---

Today I updated my system and found that Dolphin and Kate no longer run under
root.  I look and saw that this is considered a security issue.  As a Pen
Tester I run under root during testing.  I do understand that normally you
would never run under root.  When you logged in as root then why is it a
problem accessing files with dolphin?  If the problem is these is a security
hole from a normal user account because root can access files with Dolphin then
fix the problem don't just break it and turn it off this doesn't "fix"
anything.

This problem is also a problem with Kate.  So you telling me that a Text Editor
is a security problem well as a security researcher for over 20 years I can
tell you the problem is a text editor it is bad code.  don't be lazy fix the
code.

Dear developers people need to access system files from time to time and change
those files.  Since configuration files in UNIX/Linux type OSes are text files
you need a text editor to change these files.  Systems are not completed
configured during install and a person must access the system.  LeafPad and
Gedit have no problem running under root.

At least give me the ability to run these applications if I choose to.

I hate to complain I have been a user since the 1990's and have always loved
KDE for its sensible and configurable desktop.  PLEASE be sensible again and
don't screw with function.

Thank you
Bo Weaver

-- 
You are receiving this mail because:
You are watching all bug changes.