Flash Player dropped from Tumbleweed and Leap 42.1

classic Classic list List threaded Threaded
136 messages Options
1 ... 4567
Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Johannes Meixner

Hello,

On Nov 4 20:40 Andrei Borzenkov wrote (excerpt):
>>> Johannes Meixner <[hidden email]> writes:
>>>
>>>> Is it possible to have an AppArmor profile for rpm
>>>> so that rpm cannot change already existing files?
>
> How would you update third party RPM with this
> profile active?

You cannot.

This raises a subsequent issue:

I assume it is too complicated (or simply impossible)
to have an AppArmor profile for rpm so that rpm cannot
change already existing files in other packages.

Therefore "updating" third party RPMs with this profile
active whould have to be done by first removing the
installed third party RPM and then installing the
new version of the third party RPM from scratch.

I do not know how far this is feasible in practice.

In particular it seems there is no rpm erase option
like "--excludeconfigfiles" so that one could keep
the RPM configfiles after package removal.

In contrast all user-specific data is under /home/*
where it is safe because /home/* is sacrosanct.

Currently I think the sacrosanct status of /home/* for rpm
should be probably really enforced by default.


In general:

When you fully trust a third party (i.e. when you allow
that third party to work as root on your system), you can
install their RPMs "as usual" (i.e. without such a profile).


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Carlos E. R.-2
On 2015-11-05 11:42, Johannes Meixner wrote:

> This raises a subsequent issue:
>
> I assume it is too complicated (or simply impossible)
> to have an AppArmor profile for rpm so that rpm cannot
> change already existing files in other packages.
>
> Therefore "updating" third party RPMs with this profile
> active whould have to be done by first removing the
> installed third party RPM and then installing the
> new version of the third party RPM from scratch.
Different approach idea: install the rpm and somehow list or catch any
written or changed file outside of those listed by "rpm -ql ..."

Is that possible?

I know it is possible to catch the changes with something like the
seccheck scripts that run off cron, but it is heavy processing and would
find also changes not done by this install.

It would not be the best thing, but knowing what has been changed would
allow an administrator to revert the changes, and perhaps write an AA
profile that denies those same changes, for the next run.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Marcus Meissner
On Thu, Nov 05, 2015 at 01:14:18PM +0100, Carlos E. R. wrote:

> On 2015-11-05 11:42, Johannes Meixner wrote:
>
> > This raises a subsequent issue:
> >
> > I assume it is too complicated (or simply impossible)
> > to have an AppArmor profile for rpm so that rpm cannot
> > change already existing files in other packages.
> >
> > Therefore "updating" third party RPMs with this profile
> > active whould have to be done by first removing the
> > installed third party RPM and then installing the
> > new version of the third party RPM from scratch.
>
> Different approach idea: install the rpm and somehow list or catch any
> written or changed file outside of those listed by "rpm -ql ..."
>
> Is that possible?
>
> I know it is possible to catch the changes with something like the
> seccheck scripts that run off cron, but it is heavy processing and would
> find also changes not done by this install.
>
> It would not be the best thing, but knowing what has been changed would
> allow an administrator to revert the changes, and perhaps write an AA
> profile that denies those same changes, for the next run.

snapper and btrfs snapshots is made for this and can do this already;)

Ciao, Marcus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Johannes Meixner
In reply to this post by Carlos E. R.-2

Hello,

On Nov 5 13:14 Carlos E. R. wrote (excerpt):
> Different approach idea: install the rpm and somehow
> list or catch any written or changed file outside
> of those listed by "rpm -ql ..."

I assume you mean to basically compare what "rpm -ql" shows
for an installed package before updating it with what it
shows after it was updated.

I think on the one hand this would result too much
false-positives warnings or errors when updating an
installed RPM because an update can change any files
that belong to the package, e.g. things like replacing
/opt/<package>/<path>/this by /opt/<package>/<path>/that.

On the other hand what should the user do when he gets
informed that "update of <package> replaced /usr/bin/ls"?

I think the approach to "install the rpm" and do anything
afterwards does not really help - except to scare the user
after all could have been already lost.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Carlos E. R.-2
In reply to this post by Marcus Meissner
On 2015-11-05 14:02, Marcus Meissner wrote:

> snapper and btrfs snapshots is made for this and can do this already;)

Mmm... would not help me, I don't use btrfs.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Carlos E. R.-2
In reply to this post by Johannes Meixner
On 2015-11-05 14:09, Johannes Meixner wrote:

>
> Hello,
>
> On Nov 5 13:14 Carlos E. R. wrote (excerpt):
>> Different approach idea: install the rpm and somehow
>> list or catch any written or changed file outside
>> of those listed by "rpm -ql ..."
>
> I assume you mean to basically compare what "rpm -ql" shows
> for an installed package before updating it with what it
> shows after it was updated.
Well, no... rpm -ql should display the same before and after. Doesn't
it? :-?
The issue here, I believe, is what is done by scripts in the rpm, what
is not declared in advance.


> On the other hand what should the user do when he gets
> informed that "update of <package> replaced /usr/bin/ls"?

Huh. Freak out? :-))

> I think the approach to "install the rpm" and do anything
> afterwards does not really help - except to scare the user
> after all could have been already lost.

Well, it is rather for investigation, not for every user.
Me, I would prefer to know, even if it is too late.

Of course, even better would be to halt mid-install on every outside
change, and ask whether to allow or not. But that would extensive new
coding, I guess.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Christian Boltz-5
Hello,

Am Donnerstag, 5. November 2015 schrieb Carlos E. R.:

> On 2015-11-05 14:09, Johannes Meixner wrote:
> > On Nov 5 13:14 Carlos E. R. wrote (excerpt):
> >> Different approach idea: install the rpm and somehow
> >> list or catch any written or changed file outside
> >> of those listed by "rpm -ql ..."
> >
> > I assume you mean to basically compare what "rpm -ql" shows
> > for an installed package before updating it with what it
> > shows after it was updated.
>
> Well, no... rpm -ql should display the same before and after. Doesn't
> it? :-?
> The issue here, I believe, is what is done by scripts in the rpm, what
> is not declared in advance.

It's not declared by rpm -qpl - but you can easily use
    rpm -qp --scripts untrusted-package.rpm

IMHO that is the more important check compared to rpm -qpl because
things done by the scripts are typically harder to detect afterwards
(rpm -qf $file and rpm -V $package are useless if a script creates or
modifies a file, while both are helpful for files "officially" shipped
in a package).

> > On the other hand what should the user do when he gets
> > informed that "update of <package> replaced /usr/bin/ls"?
>
> Huh. Freak out? :-))

And that repairs your system? Does it also work for hacked Joomla or
Wordpress sites?
If yes, can you teach me how to correctly freak out, please? ;-)

> Of course, even better would be to halt mid-install on every outside
> change, and ask whether to allow or not. But that would extensive new
> coding, I guess.

The problem is that it will end up in *lots of* questions [1] - and that
means that the user will just put a stone on the enter key and miss the
one malicious thing in the middle of 100 other events.


Regards,

Christian Boltz

[1] lots of packages have scripts in %post etc. - being it ldconfig
    calls (done in all lib* packages), updating the bootloader, changing
    an alternatives symlink, updating font or icon cache, ...
--
> Heute habe ich die CPU gepflegt und wollte danach
> den PC starten / booten. Es gab kein Bild.
Was heißt das denn genau? Maniküre, Pediküre, UV-Bad, Cremen, ... ;)
[> Frank und T. Ermlich in opensuse-de]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Christian Boltz-5
In reply to this post by Johannes Meixner
Hello,

Am Donnerstag, 5. November 2015 schrieb Johannes Meixner:

> On Nov 4 23:45 Christian Boltz wrote (excerpt):
> > Am Mittwoch, 4. November 2015 schrieb Johannes Meixner:
> >> Is it possible to have an AppArmor profile for rpm
> >> so that rpm cannot change already existing files?
> ...
> > If you really want that, it might be possible to create
> > a profile based on the rpm -qpl output, but that won't
> > help much for %post scripts. Well, except if your goal is
> > not to let %post change anything that is not related
> > to the new package, ... ;-)
>
> Yes, my goal is not to let %post change anything that is not
> related to the new package because otherwise anything evil
> could be done via RPM scriptlets.
>
> For my personal use case see
> https://fate.opensuse.org/307745
> (excerpt)
> ------------------------------------------------------------------
> ... it downloads RPMs only from hardcoded URLs
> from OpenPrinting and inspects the downloaded RPM
> whether it overwrites already installed files on the system
> and if not, it installs it without running any RPM scripts
> because normal printer drivers do not need to run
> RPM scripts during installation.
> If the above conditions are not fulfilled it shows a very
> explicite warning text and does not install anything.
> ------------------------------------------------------------------
>
> Normal printer driver software packages do not need
> to run RPM scriptlets.

That sounds like   rpm -Uhv --noscripts printer-driver.rpm   ;-)
(and checking   rpm -qpl printer-driver.rpm   before actually installing it)

> Perhaps also for installing normal application prgrams
> there is no real need to run RPM scriptlets.
>
> The only exception is perhaps running /sbin/ldconfig
> in %post and %postun.

And fontconfig and update-desktop-files and ... ;-)

As I showed yesterday, it is possible to create a profile for zypper or
rpm, however it needs to be quite broad ("allow write access to
everything except /home/**, and also allow to execute several things
called in %post").

It should be possible to generate a profile based on rpm -qpl [1], and
maybe even separate subprofiles for things typically called in %post
(so that ldconfig can only write /etc/ld.so.cache), but I wonder if it's
really worth the effort.

The problem with such a profile is that it _will_ deny/break something
sooner or later, so I'm afraid the chance that people actually use it is
not too high...


Having a basic rpm profile ("allow everything outside of /home") might
be an option, but even that could break something if someone invents a
a new creative way to use %post.

Hmm, maybe I should really create an apparmor-profiles-paranoid package
one day ;-)

> But I wonder if this could be misused to do evil things,
> e.g. when third-party software provides its own version of
> a standard library with "special additional functionality"
> (a.k.a. backdoor).

If that backdoor is inside the third-party software, then checking
things at installation time is useless (assuming it installs that
backdoored library in a private directory, not in /usr/lib/).

Instead, you might want to create a (strict [2]) AppArmor profile for
this software ;-)

> > Speaking about printer drivers - do you think having
> > a profile for cups would be possible?
>
> I do not yet understand what you mean with "a profile for cups"
> i.e. what your intent behind such a profile should be.

I'm thinking about an AppArmor profile that allows cups to do only what
it is supposed to do (take print data from an application, convert it to
a format the printer understands, and send it to the printer). This
implicitely means to deny everything else.

With such a profile, ideally even malicious printer drivers could "only"
access the to-be-printed data, but not everything else.

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/view/head:/debian/local/apparmor-profile
is probably a good starting point, however I didn't test it yet.
The Ux (unconfined) rule used for third-party backends and some other
Ux rules look too permissive to me - and that's where you would be able
to help a lot because you know a lot about cups and possibly also know
(or even can test) lots of third-party printer drivers.

Needless to say that the footnote [2] about the strictness of the profile
also applies to cups, and that's probably why Ubuntu chose to use those
Ux rules.

> >> In contrast when installing openSUSE maintenance updates
> >> such an AppArmor profile would have to be disabled before.
> >
> > Obviously ;-)
> >
> > BTW: aa-exec allows you to invoke a program with
> > a specific profile. That's probably easier than
> > switching profiles on and off.
>
> Perhaps a more general feature request like
> https://fate.opensuse.org/307745
> for "a general tool" (not necessarily a YaST module)
> that helps a normal user to install third-party software
> in a reasonably secure way (what "reasonably secure" is
> needs to be discussed and defined) makes sense?

See above - I'd call   rpm -Uhv --noscripts   reasonable secure ;-)
Having an AppArmor profile based on rpm -qpl is something people using
permissions.paranoid might want ;-)

> > A funny detail is that some %post script creates /dev/lp*
> > - any idea why that might be needed? For bonus points,
> > tell me which package does that, and why /dev/lp* are
> > needed on a laptop that doesn't have a parallel port ;-)
>
> See
> https://bugzilla.opensuse.org/show_bug.cgi?id=673845
> for the full story.

That's a quite long story ;-)
(short version: without /dev/lp*, parallel port printers can't be
auto-detected)

> You need to find out why you got the parallel-printer-support
> RPM installed on your computer.
> As far as I know installation of this RPM is not done
> in a hardware dependant way but by a RPM "recommends"
> (actually by a "Supplements: cups").

Right, parallel-printer-support has Supplements: cups.
Now the obvious question is if we can change the installation of this
package to a hardware-dependent way ;-)


Regards,

Christian Boltz

[1] We already have a script that generates a sniplet for the samba
    profile based on smb.conf. Converting the rpm -qpl output to a
    profile sniplet is probably easier ;-)

[2] "strict" is exactly the problem - a paranoid user might like a
    profile for his webbrowser that allows writing files only to
    ~/download and reading files only from ~/public, and another user
    will find this restriction extremely annoying ;-)

--
"Der Unterschied zwischen einem Windows- und Linux-User ist der, daß
ein Linux-User lesen kann!"     [Frank Gerd Walzebuck in suse-linux]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Stefan Seyfried
In reply to this post by Dominique Leuenberger / DimStar
Am 04.11.2015 um 14:39 schrieb Dominique Leuenberger / DimStar:

> fuse per default only gives access to the user - root is blocked out
> there. In 'essence', the fuse FS driver running in user space, is the
> only one having the credentials to access the remote instance (could be
> really remote for example).

But if you are root, this "protection" is easily worked around.
So it in the best case can prevent accidents, but not attacks.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Johannes Meixner
In reply to this post by Christian Boltz-5

Hello,

becomes now probably too much off-topic because
now it is mainly about printer drivers and CUPS.

On Nov 6 01:02 Christian Boltz wrote (excerpt):
>> Normal printer driver software packages do not need
>> to run RPM scriptlets.
>
> That sounds like   rpm -Uhv --noscripts printer-driver.rpm

Of course - except running /sbin/ldconfig if needed.

>> The only exception is perhaps running /sbin/ldconfig
>> in %post and %postun.
>
> And fontconfig and update-desktop-files and ... ;-)

Here I was talking about printer driver software packages
not about arbitrary third party RPMs.


> Having a basic rpm profile ("allow everything outside of /home")
> might be an option, but even that could break something if
> someone invents a a new creative way to use %post.

But when the intent is to "forbid changing anything in /home/"
then it must break installing RPMs that would change
something in /home/ - or what do I misunderstand here?


>>> Speaking about printer drivers - do you think having
>>> a profile for cups would be possible?
>>
>> I do not yet understand what you mean with "a profile for cups"
>> i.e. what your intent behind such a profile should be.
>
> I'm thinking about an AppArmor profile that allows cups
> to do only what it is supposed to do (take print data
> from an application, convert it to a format the printer
> understands, and send it to the printer).

As far as I know the cupsd implements already some
limitations what filters and backends can do.

Furthermore normally installed filters and backends
run as user "lp" which means they are already sufficiently
restricted by traditional Unix file permission settings.

Regarding the cupsd itself:
It runs intentionally as root because
- only root can switch user to lp so that
   this way the filters and backends cannot
   compromise the cupsd itself (e.g. its config files).
- the cupsd does more than what you described.

In general we have this discussion every now and then
again and again and again and again and again and again...

And the result is always the same:
The current defaults are the currently best possible
balance between reasonable default security
and reasonable user-friendly default behaviour.

Any attempt to make CUPS more secure by default
causes complaints that then this or that functionality
doe no longer work out of the box
and
any attempt to make CUPS more user-friendly by default
makes it unacceptable less secure by default.


> With such a profile, ideally even malicious printer
> drivers could "only" access the to-be-printed data,
> but not everything else.

First and foremost you would need to describe how a
program that runs as "lp" could do "everything else"
or what exactly you mean with "everything else".


> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/view/head:/debian/local/apparmor-profile

I wonder why they need an Apparmor profile for CUPS.
With "why" I mean their reasoning behind.
I wonder what might be wrong in CUPS itself that
is not discussed on the CUPS upstream development list
and cannot be fixed in CUPS itself so that the only
way out for them is to use an AppArmor profile?

I think I will ask Martin Pitt and Till Kamppeter
about their reasoning behind.


In general regarding SUSE's printing system see
"User expectations" at
https://en.opensuse.org/Concepts_printing



>>> A funny detail is that some %post script creates /dev/lp*
>>> - any idea why that might be needed? For bonus points,
>>> tell me which package does that, and why /dev/lp* are
>>> needed on a laptop that doesn't have a parallel port ;-)
>>
>> See
>> https://bugzilla.opensuse.org/show_bug.cgi?id=673845
>> for the full story.
>
> That's a quite long story ;-)
> (short version: without /dev/lp*, parallel port printers
> can't be auto-detected)

Not "device auto-detection" but "kernel module auto-loading".
Without /dev/lp* parallel port printers cannot work because
without /dev/lp* the lp kernel module gets not loaded.


Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Graham Norton - HRB 21284 (AG Nuernberg)

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Carlos E. R.-2
In reply to this post by Christian Boltz-5
On 2015-11-05 23:30, Christian Boltz wrote:
> Hello,
>
> Am Donnerstag, 5. November 2015 schrieb Carlos E. R.:



>>> On the other hand what should the user do when he gets
>>> informed that "update of <package> replaced /usr/bin/ls"?
>>
>> Huh. Freak out? :-))
>
> And that repairs your system? Does it also work for hacked Joomla or
> Wordpress sites?
> If yes, can you teach me how to correctly freak out, please? ;-)

Of course. You have to scream wildly. Then you may get a contract for
Scary Movie 42 ;-)


>> Of course, even better would be to halt mid-install on every outside
>> change, and ask whether to allow or not. But that would extensive new
>> coding, I guess.
>
> The problem is that it will end up in *lots of* questions [1] - and that
> means that the user will just put a stone on the enter key and miss the
> one malicious thing in the middle of 100 other events.

Well, as I said, I'm considering it as tool for investigation, not for
end users.

Do you remember "checkinstall"? Somehow, it detected what "make install"
created. How did it do it? :-?

Something wrapping "rpm" so that it could list every file it writes or
modifies.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Stefan Seyfried
In reply to this post by Carlos E. R.-2
Am 05.11.2015 um 13:14 schrieb Carlos E. R.:

> On 2015-11-05 11:42, Johannes Meixner wrote:
>
>> This raises a subsequent issue:
>>
>> I assume it is too complicated (or simply impossible)
>> to have an AppArmor profile for rpm so that rpm cannot
>> change already existing files in other packages.
>>
>> Therefore "updating" third party RPMs with this profile
>> active whould have to be done by first removing the
>> installed third party RPM and then installing the
>> new version of the third party RPM from scratch.
>
> Different approach idea: install the rpm and somehow list or catch any
> written or changed file outside of those listed by "rpm -ql ..."
>
> Is that possible?

Yes. By using the audit subsystem.
You can log which process changes which files, then check if it is a
child of RPM (you don't want to wade through everything else that's
going on on a busy file server while installing Flash Player on it ;-P),
and if it is, log everything that's change. Then, after rpm is finished
installing, use this log and compare it to what the package actually
claims to have done. Combine this with a snapper snapshot before and
after the installation and it should be possible to restore things to a
working order afterwards.

Or maybe with some help of a kernel driver, we could even intercept all
the calls that a certain process does (in this case rpm and its
children) and create a backup of every file that is touched by the
installation (this is not possible AFAIK by just using audit, because
audit only *notifies* you of changes, but there is no way to intercept
the calls, so once you are notified, the file is already modified, too
late to back up).

> I know it is possible to catch the changes with something like the
> seccheck scripts that run off cron, but it is heavy processing and would
> find also changes not done by this install.

Exactly. And you would not know who had done the changes.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Stefan Seyfried
In reply to this post by Marcus Meissner
Am 05.11.2015 um 14:02 schrieb Marcus Meissner:

> snapper and btrfs snapshots is made for this and can do this already;)

This hammer is much too big. It would roll back totally unrelated changes.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Stefan Seyfried
In reply to this post by Christian Boltz-5
Am 05.11.2015 um 23:30 schrieb Christian Boltz:

> It's not declared by rpm -qpl - but you can easily use
>     rpm -qp --scripts untrusted-package.rpm

have you ever done this with commercial, third-party packages?

Example: citrix-receiver. An estimated jigawatt of %post/%pre scripts.
Totally unreadable. No fscking way I'm going to install this piece of
crap on any of my machines.
I instead used the tarballs and installed them in a separate user's home...

> [1] lots of packages have scripts in %post etc. - being it ldconfig
>     calls (done in all lib* packages), updating the bootloader, changing
>     an alternatives symlink, updating font or icon cache, ...

Well, one could whitelist packages from known good vendors, e.g. those
signed with a particular GPG key.
But still complain about packages unsigned or signed with an Adobe,
Citrix or Google key.
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Flash Player dropped from Tumbleweed and Leap 42.1

Carlos E. R.-2
In reply to this post by Stefan Seyfried
On 2015-11-06 18:50, Stefan Seyfried wrote:
> Am 05.11.2015 um 13:14 schrieb Carlos E. R.:


>> Different approach idea: install the rpm and somehow list or catch any
>> written or changed file outside of those listed by "rpm -ql ..."
>>
>> Is that possible?
>
> Yes. By using the audit subsystem.
> You can log which process changes which files, then check if it is a
> child of RPM (you don't want to wade through everything else that's
> going on on a busy file server while installing Flash Player on it ;-P),
> and if it is, log everything that's change. Then, after rpm is finished
> installing, use this log and compare it to what the package actually
> claims to have done. Combine this with a snapper snapshot before and
> after the installation and it should be possible to restore things to a
> working order afterwards.
Yes, this is what I was thinking about, but I wouldn't know how to do it :-)

Ah, another way to check changes and undo them is rpm --verify, and
those changed, reinstall. Clumsy, but doable.

--
Cheers / Saludos,

                Carlos E. R.
                (from 13.1 x86_64 "Bottle" at Telcontar)


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

CUPS and AppArmor (was: Re: Flash Player dropped from Tumbleweed and Leap 42.1)

Christian Boltz-5
In reply to this post by Johannes Meixner
Hello,

Am Freitag, 6. November 2015 schrieb Johannes Meixner:
> becomes now probably too much off-topic because
> now it is mainly about printer drivers and CUPS.

This thread already got quite some off-topic discussions, therefore I
don't see a real problem. However, I'll update the subject ;-)
 

> On Nov 6 01:02 Christian Boltz wrote (excerpt):
> >> Normal printer driver software packages do not need
> >> to run RPM scriptlets.
> >
> > That sounds like   rpm -Uhv --noscripts printer-driver.rpm
>
> Of course - except running /sbin/ldconfig if needed.
>
> >> The only exception is perhaps running /sbin/ldconfig
> >> in %post and %postun.
> >
> > And fontconfig and update-desktop-files and ... ;-)
>
> Here I was talking about printer driver software packages
> not about arbitrary third party RPMs.

I already see someone requesting a sandbox for installing font packages,
so we should not limit this to "just printer drivers". (I know there are
more third-party printer driver RPMs than font RPMs, but still.)

> > Having a basic rpm profile ("allow everything outside of /home")
> > might be an option, but even that could break something if
> > someone invents a a new creative way to use %post.
>
> But when the intent is to "forbid changing anything in /home/"
> then it must break installing RPMs that would change
> something in /home/ - or what do I misunderstand here?

No misunderstanding. In the previous mails you said that RPMs should
*never* touch anything inside /home/. Therefore I'd call that
restriction "enforcing a policy", not "breaking something" ;-)

> > I'm thinking about an AppArmor profile that allows cups
> > to do only what it is supposed to do (take print data
> > from an application, convert it to a format the printer
> > understands, and send it to the printer).
>
> As far as I know the cupsd implements already some
> limitations what filters and backends can do.
>
> Furthermore normally installed filters and backends
> run as user "lp" which means they are already sufficiently
> restricted by traditional Unix file permission settings.

I know at least one exception - cups-pdf writes the resulting PDF files
to each user's homedir, so it can't run as user 'lp'.

> Regarding the cupsd itself:
> It runs intentionally as root because
> - only root can switch user to lp so that
>    this way the filters and backends cannot
>    compromise the cupsd itself (e.g. its config files).

I'd argue that it could run as "lp" from the beginning - that would be
(at least) equally secure and wouldn't even need to switch users.
(I'm sure there are reasons why it's running as root - but "can switch
to 'lp'" is not a real reason.)

> - the cupsd does more than what you described.

I know that I provided a very quick (and possibly incomplete) summary,
but basically it describes what most users see and know about CUPS.

> In general we have this discussion every now and then
> again and again and again and again and again and again...
>
> And the result is always the same:
> The current defaults are the currently best possible
> balance between reasonable default security
> and reasonable user-friendly default behaviour.
>
> Any attempt to make CUPS more secure by default
> causes complaints that then this or that functionality
> doe no longer work out of the box
> and
> any attempt to make CUPS more user-friendly by default
> makes it unacceptable less secure by default.

Agreed, there is always the balance between security and being user-
friendly. (See also permissions.{easy,secure,paranoid}.)

And ideally an AppArmor profile would allow everything that CUPS usually
does, so it won't change anything from the user's POV.

> > With such a profile, ideally even malicious printer
> > drivers could "only" access the to-be-printed data,
> > but not everything else.
>
> First and foremost you would need to describe how a
> program that runs as "lp" could do "everything else"
> or what exactly you mean with "everything else".

For example, it could read files from the home directory if the unix
permissions allow this (755), and could then send those files to an
attacker.

The point is: Even if running as 'lp', it can access data that it
shouldn't be able to - and that's where an AppArmor profile could be
helpful.

> > http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/v
> > iew/head:/debian/local/apparmor-profile
> I wonder why they need an Apparmor profile for CUPS.
> With "why" I mean their reasoning behind.
> I wonder what might be wrong in CUPS itself that
> is not discussed on the CUPS upstream development list
> and cannot be fixed in CUPS itself so that the only
> way out for them is to use an AppArmor profile?

The answer is probably https://startpage.com/do/search?q=cups+exploit
and especially the things that are not yet listed there (in other words:
unknown security flaws in CUPS).

I know that nobody intentionally writes buggy code, but it's a fact that
all software has bugs [1], and some of them can be exploited.

AppArmor can at least prevent exploits that access files which are not
allowed in the profile and therefore reduce the possible damage.
(It can also deny other things like network access / "sending out
files", but we probably have to allow network usage for CUPS to support
network printers.)

> I think I will ask Martin Pitt and Till Kamppeter
> about their reasoning behind.

Please do that, I'm also interested in the answer ;-)

(I wouldn't be surprised if the answer is "additional security".)


Regards,

Christian Boltz

[1] well, a simple hello_world.py is probably bug-free [2] ;-)
    but anything bigger than that has a good chance to contain bugs.

[2] even that could be incompatible with python 3.x ;-)
--
liegt es vielleicht an den lauschigen 34°, die der Prozessor oder sowas
nicht mitmacht? -> Soll ich mit dem Rechner jetzt zum Baggersee rausfah-
ren und ihm ne Abkühlung verpassen... [Sebastian Schulze in suse-linux]

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

1 ... 4567