Page 2 of 2 1 2
Reply
Thread Tools
pichlo's Avatar
pichlo is offline pichlo
2016-02-15 , 10:43
Posts: 6,447 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#11
Originally Posted by Feathers McGraw View Post
Jolla should ship sensible and secure defaults.
No dispute over that!

An attacker with root privileges can clean up after themselves. It doesn't make any sense to throw away that security boundary unnecessarily.
<snip>
I pointed this out before, and someone noted that you can't add a repo without root.
Yes, both good points.

But I am a bit confused now. In a post just above, you listed a procedure assuming a physical access to the device. If you have that, you can add and remove repos at will, as a user, using just GUI tools (Warehouse or simply tick the "allow untrusted sources" box in Settings). You do not need the root password at all.

The damage you can do without root is limited and relies on malicious software in trusted repos, or the existence of apps in those repos that could be exploited to gain root.
Or planting a malicious app yourself and running pkcon install-local. That also works without root and allows you to really gain a root access in 30 seconds remotely, once you brute-force your way in as a user.

I don't understand why people are trying to pass this off as unimportant.
Sorry, that was a slight misunderstanding. I am not trying to pass it off as unimportant. All I am trying to say is that there is an even bigger hole gaping in the system in addition to the one you have pointed out.

What I do not understand is how can anyone try to pass Sailfish off as a secure OS. The only "security" we have ATM is through obscurity. The worst kind there is.
__________________
Русский военный корабль, иди нахуй!
 

The Following 4 Users Say Thank You to pichlo For This Useful Post:
juiceme is offline juiceme
2016-02-15 , 11:38
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#12
I think most of the problems stem from the convention in current SFOS that there is just one "nemo" user account and many system services depend on the user being "nemo" to work correctly.

True multiuser capability should make the device more secure (among other benefits)

I already started to work on separating system priviliges from "nemo" priviliges, to enable multiple user accounts on the device but got a bit sidetracked some time ago so have not really had time to continue with it.

What I'd like to see in the end are following results;
  • system startup does not depend on user login at any level
  • multiple user accounts that can log-in simultaneously
  • all user accounts have their own set of privilige controls
  • all system services needing user-related data for operation depend only on data in home of the said user (well, this is kind of obvious, really )
  • all installed applications needing user data depend only on data in home of the said user (which actually works like that already)
  • all user homes are encrypted by default
 

The Following 5 Users Say Thank You to juiceme For This Useful Post:
pichlo's Avatar
pichlo is offline pichlo
2016-02-15 , 11:45
Posts: 6,447 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#13
@juiceme, wonderful!

I would add,
  • abolish any hard-coded names: on the first boot, the user chooses the user name

There is already the "choose your colour" thing on the first boot, without any explanation WTF that is for. Choosing the user name would make more sense, IMHO.
__________________
Русский военный корабль, иди нахуй!
 

The Following 5 Users Say Thank You to pichlo For This Useful Post:
juiceme is offline juiceme
2016-02-15 , 12:33
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#14
Originally Posted by pichlo View Post
@juiceme, wonderful!

I would add,
  • abolish any hard-coded names: on the first boot, the user chooses the user name

There is already the "choose your colour" thing on the first boot, without any explanation WTF that is for. Choosing the user name would make more sense, IMHO.
Yes, very easily doable.
Actually the username "nemo" group "nemo" (10000:10000) is arbitrary and could be changed to anything desired even now without any adverse effects. It would indeed be nice to set up the "main" user to whatever desired in the startup wizard.

All in all it is not that large a task to implement all these things; the biggest thing is to hack the GUI so that when the wayland backend starts it does not autolaunch lipstick with nemo credentials; instead it should launch up user login selector.
It needs just some heavy-handed systemd tweaking to do, plus pruning the system services dependant on "nemo" login for startup.
 

The Following 4 Users Say Thank You to juiceme For This Useful Post:
Feathers McGraw's Avatar
Feathers McGraw is offline Feathers McGraw
2016-02-15 , 22:02
Posts: 654 | Thanked: 2,368 times | Joined on Jul 2014 @ UK
#15
Originally Posted by pichlo View Post
you can add and remove repos at will, as a user, using just GUI tools (Warehouse or simply tick the "allow untrusted sources" box in Settings). You do not need the root password at all.

Or planting a malicious app yourself and running pkcon install-local. That also works without root and allows you to really gain a root access in 30 seconds remotely, once you brute-force your way in as a user.
I didn't know about pkcon install-local, that's interesting/slightly disturbing if you can use it in the way you are describing.

Having reviewed the polkit settings, I must say I don't understand why you're allowed to do some things with packagekit...

Here's a truncated version of the settings:

Code:
nemo ~ $ cat /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy | grep -v "[message|description] xml"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd">
<policyconfig>

  

  <vendor>The PackageKit Project</vendor>
  <vendor_url>http://www.packagekit.org/</vendor_url>
  <icon_name>package-x-generic</icon_name>

  <action id="org.freedesktop.packagekit.cancel-foreign">
    
    <description>Cancel foreign task</description>
    <message>Authentication is required to cancel a task that was not started by yourself</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.package-install">
    
    <description>Install signed package</description>
    <message>Authentication is required to install a package</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.package-install-untrusted">
    
    <description>Install untrusted local file</description>
    <message>Authentication is required to install an untrusted package</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.imply">org.freedesktop.packagekit.package-install</annotate>
  </action>

  <action id="org.freedesktop.packagekit.system-trust-signing-key">
    
    <description>Trust a key used for signing packages</description>
    <message>Authentication is required to consider a key used for signing packages as trusted</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.package-eula-accept">
    
    <description>Accept EULA</description>
    <message>Authentication is required to accept a EULA</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.package-remove">
    
    <description>Remove package</description>
    <message>Authentication is required to remove packages</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.imply">org.freedesktop.packagekit.package-install</annotate>
  </action>

  <action id="org.freedesktop.packagekit.system-update">
    
    <description>Update packages</description>
    <message>Authentication is required to update packages</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.system-sources-configure">
    
    <description>Change software source parameters</description>
    <message>Authentication is required to change software source parameters</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.system-sources-refresh">
    
    <description>Refresh system sources</description>
    <message>Authentication is required to refresh the system sources</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.system-network-proxy-configure">
    
    <description>Set network proxy</description>
    <message>Authentication is required to set the network proxy used for downloading packages</message>
    <icon_name>preferences-system-network-proxy</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.device-rebind">
    
    <description>Reload a device</description>
    <message>Authentication is required to reload the device with a new driver</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/pk-device-rebind</annotate>
  </action>

  <action id="org.freedesktop.packagekit.upgrade-system">
    
    <description>Upgrade System</description>
    <message>Authentication is required to upgrade the operating system</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.repair-system">
    
    <description>Repair System</description>
    <message>Authentication is required to repair the installed software</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
  </action>

  <action id="org.freedesktop.packagekit.trigger-offline-update">
    
    <description>Trigger offline updates</description>
    <message>Authentication is required to trigger offline updates</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/libexec/pk-trigger-offline-update</annotate>
  </action>

  <action id="org.freedesktop.packagekit.clear-offline-update">
    
    <description>Clear offline update message</description>
    <message>Authentication is required to clear the offline updates message</message>
    <icon_name>package-x-generic</icon_name>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/libexec/pk-clear-offline-update</annotate>
  </action>

</policyconfig>
I just tried installing a package with pkcon via ssh to test installing a signed package, which should come under allow_inactive because I'm not logged in locally:

Code:
nemo ~ $ pkcon install harbour-flashlight
Installing
Waiting in queue
Starting
Refreshing software list
Querying
Resolving dependencies
Installing packages
Installing
Waiting in queue
Waiting for authentication
Waiting in queue
Starting
Refreshing software list
Querying
Resolving dependencies
Installing packages
Downloading packages
Installing packages
nemo ~ $ which harbour-flashlight
/usr/bin/harbour-flashlight
This action has allow_inactive no, so why did it succeed? Also, why is the output from polkit so terrible? Is it meant to be easy to parse or something?

I'm basing my understanding of allow_inactive on the Arch wiki:
Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. allow_any is the setting encompassing both scenarios.
Maybe it doesn't count as a "remote" session if the same user is logged in locally at the same time?

Anyway, by the same logic, I would expect those polkit settings to deny attempts to install untrusted local packages remotely, and only allow local users to install local packages after authentication.

And yet...I just tried installing by selecting an RPM in filecase it and it succeeded. :s

It seems the wheel group would have permissions to do this:


Code:
nemo ~ $ sudo cat /etc/polkit-1/localauthority.conf.d/50-localauthority.conf 
# Configuration file for the PolicyKit Local Authority.
#
# DO NOT EDIT THIS FILE, it will be overwritten on update.
#
# See the pklocalauthority(8) man page for more information
# about configuring the Local Authority.
#

[Configuration]
AdminIdentities=unix-group:wheel
...but nemo isn't in it:

Code:
nemo ~ $ groups
nemo video users ssu timed oneshot system bluetooth graphics input audio camera mtp
The only other thing I could find is this:
Code:
nemo ~ $ sudo cat /etc/polkit-1/nullbackend.conf.d/50-nullbackend.conf
#
# Configuration file for the PolicyKit null backend.
#
# DO NOT EDIT THIS FILE, it will be overwritten on update.
#
# To change configuration, create another file in this directory with
# a filename that is sorted after the 50-nullback.conf and make
# sure it has the .conf extension.
#
# Only a single configuration item, Priority, is supported.
#
# See the PolicyKit documentation for more information about PolicyKit.
#

[Configuration]
Priority=-10
Code:
nemo ~ $ rpm -qf /usr/lib/polkit-1/extensions/libnullbackend.so 
polkit-0.104-1.1.6.armv7hl
Could this be an extension backend written by Jolla, responsible for allowing authentication by other methods? Or is it part of nemo (which would explain why it's in polkit itself, and not some other Jolla specific package)?

Sorry, that was a slight misunderstanding. I am not trying to pass it off as unimportant. All I am trying to say is that there is an even bigger hole gaping in the system in addition to the one you have pointed out.

What I do not understand is how can anyone try to pass Sailfish off as a secure OS. The only "security" we have ATM is through obscurity. The worst kind there is.
Agreed what we have now may be convenient, but it seems like it was thrown together in a rush without much regard for security (would implementing the kind of things juiceme mentioned make the system a pain to use? I don't think it would.)
 

The Following 2 Users Say Thank You to Feathers McGraw For This Useful Post:
Reply
Page 2 of 2 1 2

Tags
devel-su, jolla, root access, sailfish, ssh daemon

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 01:05.

Contact Us - Home - Archive - Top