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

Peter Dolding oiaohm at gmail.com
Wed Dec 17 19:19:13 PST 2008


On Thu, Dec 18, 2008 at 6:21 AM, Thomas Leonard <talex5 at gmail.com> wrote:
> 2008/12/16 Peter Dolding <oiaohm at gmail.com>:
>> On Tue, Dec 16, 2008 at 5:56 AM, Thomas Leonard <talex5 at gmail.com> wrote:
> [...]
>>> 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.
>
> So users can update the kernel's policy and set security labels on
> their files? I didn't know that, but however you want to implement it,
> that's fine. The information you have when a package is run is:
>
> - The URI of the program
> - The path of the file the user dragged to it, if any
>
> That should be enough to have a sensible default policy that keeps
> applications separate (particularly configuration files). Plash allows
> applications to communicate with a separate process if they want to
> display a save as/open dialog. The process then grants the running
> application access to the chosen file. I'm sure SE-Linux could do the
> same.
>
Explained latter you like policy enforced before you run the program if you can.

Once files are taged secuirty ID's can stay with them.  Plash is
different to selinux.

Plash runs applications virtual.   Selinux is using before run taging
to define limits.  Yes selinux allows or blocks if a application can
take to particular processes based on rules applied before application
is run.

selinux also directly can integrate with firewall.   Plash does not
cover as many sides as completely as selinux.   Selinux can control
network chatter between applications.   Selinux also does not have
overhead like Plash since its not emulation is just the permission
system of the OS blocking it from doing the wrong thing.

>> 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.
>
> How can you do that (e.g. using RPM, etc)? Can the possibly-malicious
> software add a file to /usr/bin, /usr/lib or /sbin? If not, it's going
> to fail for a lot of packages. If so, it's hard to see how it can be
> secure.
>
That comes down to extra options.

Installer can write to /usr/bin....  core directories.  Installer can
also check package for signature and for a existing approved
selinux/smack policy for that application.   No approved policy no
installation.

selinux also block application interfacing with applications and .so
files they would not have normally interfaced with.

role and user access can also be assigned to applications.
Particular applications can be taged not admin or like internet.

Internet is a common role tag I use.   Normal business directories are
locked off from the in the user account.    Yes role based secuirty
under selinux allows a single user to have many different access
configurations.

${home}/Downloads  I have set quite commonly as the only directory
other than firefox's configurations it can read in the user accounts.
 No matter what firefox's trys or anything else running inside firefox
or executed by firefox can get out of this lock.

>> 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.
>
> So what extra hooks are required? Say the user runs
>
> $ 0launch http://example.com/foo.xml
>
> I guess you need to intercept this, and turn it into something like:
>
> $ 0launch --get-selections http://example.com/foo.xml > selections.xml
> [ enter sandbox for http://example.com/foo.xml ]
> $ 0launch --set-selections selections.xml
>
> The first downloads the program and adds it to the cache, but doesn't
> run it. The program shouldn't get the chance to do any damage here.
> The second command runs the cached program from the first step, which
> can run in a very restricted environment.
>
> (in real life you'd do this with a Python script rather than messing
> about with temporary files, of course)
>
More like user sets that they don't want 0install applications having
access to particular directories and the like.  0install makes
applications obey by using sandboxing options if it has them.

This is basically allowing users to protect them-selfs.   Now
applications that just need to store a configuration file in the users
account could be locked that is all they can touch.   Not all
application you handle need access to everything.

Problem we have here is 0install understands
http://example.com/foo.xml  No security system on Linux does.  So
files are downloaded into cache.  Links from user accounts in the
.cache directory.  Yes secuirty systems on Linux solarias bsd talks
files.  We have a language problem.  Translation somehow from URI of
0intall to operational secuirty rules has to be made.

If system admin wants to defend applications with selinux smack or
anything else 0install system makes it down right hard.

Some form of bridging application is needed.   Yes system admins would
be prepared to grant something like 0install the rights to add new
rules to smack or selinux if they were sure the program doing it was
not harmful and was improving the over all secuirty.

Hard bit is really designing the points to hook the security
interfaces in.  It might be adding another stage.

Download to shared cache
request usage ie overrides the shared cache rules of block execution
to everyone.  Of course if admin does not approve you using that
application its access not granted.
run application


Mirror revoke usage also has to exist.

Trying to run before request usage is approved would fail.    This
would be making the cache truly not trusted from linux secuirty point
of view.   Person or application cannot go in there and randomly run
stuff.

selinux sandbox is still a selinux.  Before you can run something tags
have to be connected to files.  Yes slightly longer process than
current method.   Way more secure.  Secure before run is simpler than
trying to secure on fly.

>> You hit is in one.   How can I currently have the advantage of zero
>> install and treat users as 100 percent malicious.
>
> I guess I don't really understand why your users are trying to get
> around your security policy. Why not let them run whatever they want,
> given a suitable sandbox (do you let them run JavaScript in their
> browsers?). Even something as extreme as running untrusted apps in
> vmware or something might make them happy.
>
This is a little bit of not understanding admins.

Depends really on the system some systems they are not even allowed a
web browser.
Users themselfs not trying but running defective software then can be
breached by someone else who is trying to breach the system.

Suitable sandbox options are missing from zeroinstall.   So this means
for admins could hours wasted per application creating selinux rules
and other methods to keep the zeroinstall application secure.  So yes
it ends up back to distributions that ship premade rule sets to save
time.

>>>> 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 there are no known defective program installed.
>
> I guess this is the issue. Zero Install regards the cache as
> untrusted, in the sense that it doesn't care if there's malicious code
> in there, only that it's correctly labelled. A solution that would fit
> better would be to prevent the malicious code from getting run, rather
> than preventing it from getting cached.

Yes that that is something that is annoying admins.  Its also how do
we clean the cache speed effective of malicious code if it does slip
in.  Really admins will want to prevent both running and caching.  If
something is defective we don't want a copy left anyone in the
machines under our control that secuirty miss allocation might lead to
a user running it.  Now running before trust is granted that is
another matter we don't like.

Current system has no option for download scan with something then use
all the time with no way to run until passed the scanning stage.

Your define if untrusted is not admins define of untrusted.
Untrusted means you don't allow it to be run threw any means without
secuirty system telling it what it can and cannot do from a system
admins point of view.

Since you use URI a black list service for known evils would be good as well.

>>>> 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.
>
> There shouldn't be any symlinks. After all, the cache can be shared
> between virtual machines or over a network, and mounted at different
> places on each. Can you give an example of a symlink you've found?
>
> (symlinks in upstream packages will be unpacked faithfully, but they
> won't be adjusted depending on where the archive was unpacked)
>
>> So a backup typo does not turn into a mother of a disaster.    Every
>> user has .cache with symbolic links to central store.
>
> I don't understand this. Can you give an example symlink? The only
> possibility I can think of is if a program creates a symlink to some
> of its files when run (I think Blender symlinks its configuration
> files to the defaults when run, for example, but it's not too serious
> if they're missing).

Operation of 0install itself.  Explain later on.
>
>> 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.
>
> There's no way to avoid that on any system. If the laptop doesn't have
> the program they want, and it won't have network access on the road,
> then you have to copy the program onto the laptop first.
>
> The two possible compromises (copying all the user's programs and
> being slow, or copying none of them and not having some program) are
> both supported. Personally, I'd copy none and tell the users to try
> running any program they're going to need to make sure they've got it.

Only transfer the programs the user has used to the machine is faster
than transferring a large general cache out a server to laptop.

Issue where this is going wrong /home/{user}/.cache/{symbolic links}
Copy that with follow links it is expanded without need.

Symbolic links to system cache need to stay pointing to general cache
on the laptop.   Ie running in a non synced state between cache.   A
tool to move users from system to system making system admin life
simple make them like zero install more.

Ie something to process and transfer the users .cache directory to
make sure the shared cache on laptop or other computer is synced with
what user is using.

And something to scan threw all users .cache files producing a list of
items that could be deleted prefered with an transfer to central
server.  Problem here becomes processing time.

Take uni at the low time there is over 20000 users on a system.   Some
install system that is install once all users get applications and
remove once all user loss applications is really required when you get
on big systems.  Too complex to process accounts.

Yes you will find any information status thing admins want in a
central server were they can control it.  Yes I know feed files might
not seem like much.  They do add up over time.

>
>> Then there is a worse using mobile phone rates to
>> download applications that would be a night mare from hell.
>
> At least they have the option. Hotels usually offer tolerable Internet access.

Don't come to my country then.  Most Hotels here don't offer Internet
access at all.  Even worse lot of internet cafes here don't allow you
to plug your own machine in.

So yes the temptation to use the company phone can get the better of them.
>
> [sudo vs policykit]
>> Difference from sudo to Policykit is that you use a service with the
>> different privilege instead of and application.
>
> But how do you get the service running in the first place? Though I
> agree it would be better than setuid if you can do it. 0launch doesn't
> care what technology you use. It invokes your
> "0store-secure-add-helper" script to add the current directory
> (freshly unpacked from the download) to the system cache. The example
> script uses sudo to get access because most systems have that, but you
> can send the directory to a service if you prefer.
>
Policykit is activated threw dbus.   Same with service to perform the
high task for you is also activate threw dbus.  Only service that
stays running all the time is dbus.

http://hal.freedesktop.org/docs/PolicyKit/model-theory-of-operation.html
 << Might explain it better.

Yes really useful way of doing this.  Also removes the need for the
application to know exactly where the service/interface is installed
as well.

Integration with package kit since it already uses policykit might be
another way as well with fall backs onto sudo and the like.

Peter Dolding


More information about the packaging mailing list