[packaging] Meeting next week to discuss trusted third-party repositories

[Peter Dolding]

On Tue, Dec 16, 2008 at 5:56 AM, Thomas Leonard <talex5 at gmail.com> wrote:
> 2008/12/15 Peter Dolding <oiaohm at gmail.com>:
>> On Mon, Dec 15, 2008 at 6:48 AM, Thomas Leonard <talex5 at gmail.com> wrote:
> [...]
>>> I much prefer the current system, where I know that adding a new
>>> program isn't going to affect any existing programs.
>>
>> That comes down to how its registered.   If vendor-gtk was the tag
>> thrown into the native package manager applications making up the
>> native distribution would not even see it. Since they are looking
>> for the tag gtk.  Yes having a formal standard on naming is kinda
>> required to avoid distribution third party conflicts in the package
>> manager.
>
> OK, but there's not much point "integrating" with the package manager
> if you then name
> everything to avoid any interactions. Might as well keep them separate
> in the first place.

Its part of auditing explained at end.
>
>> Since openlina dependencies  are all inside chroot applications
>> outside are not effected.   Major reason for them wanting to register
>> in the main Distribution is for end user so they only have to go to
>> one place to remove applications.
>
> OK, so uninstalling applications should be done in the same way
> regardless of which mechanism was used to install them. After removing
> an application you'll usually want to get rid of any unneeded
> libraries too. Debian has "apt-get autoremove". Maybe package managers
> could register other handlers to get called at the same time?

Most package mangers have a run script on uninstall to clean up.   So
yes 0install list package could be integrated with the most out there.

Package kit is kinda heading in the right direction I just wish we
could get all the individual package designs really to sit down and
design a single framework covering them all and be happy with it.
Since we cannot we have to be happy with Packagekit.

>>>> 0install does have its flaws as
>>>> well.
>>>
>>> Quite possibly ;-) But what would be really useful would be specific
>>> reports from software authors, e.g.
> [...]
>> I am not guessing.  Most common flaw with 0install is fine grained
>> security not being used when its on offer. Selinux Smack and so on.
>
> Security is the main issue for people? If only if were true ;-)
>
> I guess it depends on your perspective. Here's a typical scenario I
> want to support:
>
> - User gets given a file in some odd format (pdf say) and they need to
> get a third party viewer for it.
> - User wants to install the viewer and read the file with minimum risk.
>
> SELinux, AppArmor and Smack don't seem to help here, because the
> policy has to be set by the admin, before they even know what the user
> wants to do. The best you can do is something like:
>
> - Acroread has read access to all the user's files.
> - Acroread has no write access.

That depends on the distribution.   You are badly wrong about selinux
always needing admin to set rules.

Yes you can write a Selinux policy that allows safe installation of
malicious software.  Selinux supports sand-boxing and role base and
user base allocation of access.   It provides two different methods to
solve you shared directly security problems.

Using Selinux sandboxs on every account.   This allows users without
admin rights to set selinux rules for what applications can and cannot
access in there own account without being able to override the system
wide settings.   This is what I am talking about there are systems out
there that provide it even when its on offer 0install does not use it.
 When installing system wide option of applying selinux and smack
rules around the application should be on the table.  As well as
integration if user has selinux sandbox.

Yes inside the selinux sandbox they can run there own roles and what
ever selinux design they like inside there own space as long as they
don't try to do stuff above there rights.

http://seflow.sourceforge.net/macro-provide_sandbox.php   There are
better sandbox script out there this one I could just find quickly.

Same sandboxing is used around chroots and the like with selinux so
contained distributions security system still works.  Expect to see
more LSM's over time provide this feature.  Yes selinux does not only
have to be admin controlled.  There are many reasons why it needs to
be both.

>
>> Not used to reduce the damage a 0install application could do to the
>> user account.  Not all applications need to write files everywhere in
>> the user account.
>
> Sure. Every Zero Install application is started with a call to
> "0launch URI", so you can set a system policy there (e.g. be more
> restrictive if you don't recognise the URI). The best approach depends
> on whether your users are malicious or just ignorant (unless they're
> ignorant enough to type random commands from strangers to get things
> working, in which case either treat them as malicious, or provider
> better support so they ask your support team first).

You hit is in one.   How can I currently have the advantage of zero
install and treat users as 100 percent malicious.

Preference that the user does not even know that 0install is there
when they cannot install things so they don't bug support or admin
over it.

Yes this is the other night mare of the 0install design admin delete a
application user finds out admin did even that there is a newer
version in the cache.   So users come and ask why.   When you get 200
of them doing it is down right time wasting.

Please provide admins with system wide 0install system with a system
wide change without users being made aware of it.  Save our phones and
support desks pain.

>> Also as a system admin I personally don't like users installing files
>> in there own accounts.  In fact I go as far as having a filter on
>> there accounts so they cannot.  It selinux based and it does kill zero
>> install out right.
>
> If you turn on system-wide sharing then your users won't have to
> install to their home directories:
>
>  http://0install.net/sharing.html
>
> Alternatively, you could install things to the system cache and let
> the users pick them up from there ("0launch --download-only" as a user
> with suitable privileges).
>
There are reasons why the fails badly covered in the symbolic link section.

>> Not registering in package database makes 0install harder to track for
>> system admins.   Lot of tools out there will pull the main package
>> manager database to a central location for monitoring.
>
> What are you trying to monitor, and why? That the sys admin hasn't
> installed something the monitors don't approve of? To keep track of
> what services are running?
>
That there are no known defective program installed.  If there is one
installed normally the automatic scripts send out to client to
uninstall or update it.   Basically a central server blacklist.   We
find something bad we blacklist it and very quickly it disappears from
the networks.    Yes it can be simple as a laptop that has been off
line for many months and an application that was meant to be deleted
was still on it.  Central monitoring is a catch all that slips past
us.

Service monitoring is also part of these frameworks of course ie
uninstalls something that has a running service it kills the service
first.

>> 0install is not space effective system admins don't want symbolic
>> links for no good reasons.
>
> What symlinks are you talking about?
>
> Zero Install is very efficient. It shares libraries between programs.
> It shares programs between users (if you turn on system-wide sharing).
> It shares files between packages (0store optimise). It even shares
> packages between virtual machines (even virtual machines with
> different operating systems and architectures):
>
>  http://0install.net/virtual.html

In the home account itself.  System admins prefer not to have symbolic
links pointing out side from there if they can.

So a backup typo does not turn into a mother of a disaster.    Every
user has .cache with symbolic links to central store.  Now this is
where it goes badly wrong.   When you are packing a user to transport
between systems you will sometimes set follow symbolic links so all
the files they have are got.   All the nice space effectiveness of
Zero Install goes out the window in one typo.

0install last time I tried this did not pickup that it had happened so
it stayed duplicate to the cache for the user.  Maybe you have fixed
this.   On system where I am moving users between systems all the time
I prefer if you don't have any symbolic links in the user account
pointing outside.   Some other all user system for system admins would
allow us to avoid this when zero install is not suitable due to
operational restrictions.  Not that we don't want the applications
zero install offers.

Laptops are some of the biggest causes if needing to transfer users
account from network to outside machine and back.  0install is lacking
the framework to make this process painless for admins.   If we run
0install we will get complaints from users on the road without
internet connection that the applications they want don't work if we
don't copy with follow links.    Yet if we use follow links we bloat
the user account.  Then there is a worse using mobile phone rates to
download applications that would be a night mare from hell.  Really
don't want to be syncing the full cache on to a laptop if its not
needed either.   Its a speed thing user comes in normally at the last
min wanting the stuff on a laptop most of the times someone who can
effect funding.   So yes this must be able to work perfectly every
time.

Should have worded it better space effective was not the right words.
 Painful for admins because one wrong copy it can expand in size on
them or not work after transfered.
>
>> Hopefully at some point 0install moves from sudo to policykit where
>
> Correct me if I'm wrong, but I though that policykit exists to make
> policy decisions (a PDP in XACML terms), not to allow running programs
> with extra privileges. Don't you have to use both together?

Policykit is a interface that can run a service at a higher privilege
or different user to perform a task.

Difference from sudo to Policykit is that you use a service with the
different privilege instead of and application.   And that application
trying to call service can be rejected because its the wrong
application.

Sudo is a black box.  You know user has sudo rights but you don't know
if your application was called by the right application the users end.

Policykit way could option up another option as well.   Instead of
user installing request is placed that goes to the system admin to
approve or reject.   Failed requests can be logged.

>
> If you turn on sharing then the files in the cache won't be owned by
> the users and none of their applications will be able to modify them
> anyway. Even if you don't turn on sharing, you can use SELinux to
> restrict users' access to their own caches and then provide a
> "0store-secure-add" script that does have write permission.
>
>> By the way dep and rpm integration 0install currently got could be
>> expanded a lot by integrating with http://packagekit.org/
>
> Sure.
>
>> That is not a software authors problem.  That is a person like me
>> problem.   I try to run highly secure systems 0install is kinda
>> lacking in my needs.   Auditing and securing is major parts of a
>> system admins job and 0install is making it harder.
>>
>> 0install is doing a really good job of remembering the developers and
>> the users.   Its forgetting the admin's who have a different set of
>> preferences and some of the things it doing its becoming hated by us
>> admins.   Admins not the people you really want to be annoying we do
>> have selinux and smack in our toolkits to make stuff we don't like not
>> functional.
>
> That's exactly why we need to collect their/your requirements. Could
> you explain exactly what kind of auditing your require?
> There's "0store verify" to check that a package's contents haven't
> been modified. I was planning a "0store audit" to check all
> of them at once, though it's easy to script it anyway. What else do you need?
>
Audit central to location if something defect is installed somewhere
in the network I find it quickly even better able to get rid of it for
good.  Black lists would be really handy.   Worst nightmare for admins
is trying to uninstall something from the network because its bad and
users reinstalling it because its funny.  Yes that is not fun.   Yes
these systems are currently highly automatic once the central server
controlling the installed is set to remove something as soon as
laptop/machine gets its installed checked and server finds something
that should not message is send straight out to delete it.

As I say you guys are close.   Thinking from the eyes of a system
admin seam to be missing from 0install design.   First thing to
remember a good system admin the users don't even know who the person
is because they never need them and never aware of what they have
fixed.   0install in places breaks the admin's loved invisibility.
Yes in big companies there are always a few system admins who don't
deal with support problems.   For the simple reason they get around
better and hear more.   Yes it was fun being a system admin at the
same time being the mail guy.  Found out a lot of flaws that were
being used by staff.   Some people had a really hard time when I was
leaving the company believing that I was one of the system admins.
Personally loved the mail run it was a good walk and gave my mind a
rest.

Peter Dolding