[Dev] Update of security framework repositories

Schaufler, Casey casey.schaufler at intel.com
Tue Feb 25 18:20:14 GMT 2014

> -----Original Message-----
> From: Tomasz Swierczek [mailto:t.swierczek at samsung.com]
> Sent: Monday, February 24, 2014 11:31 PM
> To: Schaufler, Casey; Macieira, Thiago; dev at lists.tizen.org
> Subject: RE: [Dev] Update of security framework repositories
> > The changes proposed are in complete conflict with the Smack three
> > domain
> model. The code needs to be brought into compliance with the Smack three
> domain model.
> > I am not objecting to the *method* of integration, I am objecting to
> > the
> code. There needs to be a general rework of the code to conform with the
> three domain model.
> This is why we put it here to rework and continue work from place where we
> left it, I think this is what we discussed with Michael and you in September.
> Fact is that mobile profile is not working properly and we'd like to fix it.
> Maybe merge directly to tizen branch is not the best idea, maybe a
> temporary place for work - but public so that you can have a look - is a better
> idea.

I think that a public (but not tizen) branch is a good idea.

> We're not opposing to 3-domain model, to be clear - the fact that the code
> *allows* to break it, doesn't mean it does. Manifests also can contain labels
> like "foo". If you look carefully, any configuration (mapping to smack rules) is
> kept in separate repository that was *not* updated (we've moved any real
> smack configuration to smack-prifilege-config repo). No one said all privileges
> we used to have will not map to one label (not AMB, but MobileMB for
> example). Especially with a PolKit/gsso/?? solution controlling access to APIs
> (which doesn't seem to be there, ready, on IVI).

There are a bunch of files that contain Smack rules in the
libprivilege-control/permissions directory. Many of these
rules provide rw access. It is OK for peer domains to have
rw access, but I would like the intent documented. Why
are they labeled differently if they have full access?

> Security server socket labels are labeled "*", and should probably belong to
> System domain - right now this would (probably) break some code. Apart
> from that, we have re-worked this module to use systemd, work faster - and
> lot of the ugly code has disappeared.

Yes, I saw. That is good.

> Libsmack - I understand that fast loading of rules may not be needed
> anymore. Systemd is indeed a good place to load rules. But why nuke
> optimization?

There's a famous case (urban legend?) of a school that was designed
as a two story building. The budget was cut, and they scaled it down
to a single story. When it opened everyone was surprised to see
an elevator in the lobby. 

The point is that unnecessary code doesn't help and can
get in the way.

> I believe this is the beginning of discussion that we'd like to participate in and
> just make the code better. This is not act of trying to force our point of view.
> No one pushed code directly to the repo.
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
> >
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

More information about the Dev mailing list