10:27 a.m.
Apparently the new version of polkit brings in javascript. The js package is
6.5MB. I think anything that uses polkit will depend on it -- can we remove
it from core?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:43 a.m.
On Fri, 09.11.12 11:27, Matthew Miller (mattdm(a)fedoraproject.org) wrote:
Apparently the new version of polkit brings in javascript. The js
package is
6.5MB. I think anything that uses polkit will depend on it -- can we remove
it from core?
We can work towards that but it requires a bit of changes in systemd. A
number of systemd services check with PK for authorization if an
unprivileged user tries to execute a privileged operation. Since we
never really tested this on systems that lack PK the fallback code that
bypasses PK if it is not around didn't really get the testing it
deserved. Just today I made a minor fix to systemd git to deal nicely
with PK-less systems.
So, I think it makes sense to make PK truly optional, but this needs a
bit of love in some layers of our stack, not just systemd but others as
well, I presume. If somebody wants to work on it, please do, and file
bugs whenever you notice that you get a PK related error message where a
fallback to classic Unix UID-based security doesn't work as it should.
David actually documented explicitly that daemons should fall back to
classic Unix-style uid-based authoization if PK is found not to be
around. It's clearly systemd's fault that we so far didn't follow this
fully.
Of course, it should be clear that making PK optional if a desktop is
installed is not desirable, but other than that I think for head-less
systems such as servers or embedded making PK optional would be
desirable goal and worthwile to spend a bit of work on.
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:15 a.m.
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote:
Of course, it should be clear that making PK optional if a desktop
is
installed is not desirable, but other than that I think for head-less
systems such as servers or embedded making PK optional would be
desirable goal and worthwile to spend a bit of work on.
Cool, thanks for the input. There's little risk of it becoming optional on
the desktop, because a large number of desktop packages sensibly have it as
a requirement -- including gnome-shell and kde-runtime. (Xfce doesn't seem
to have anything that directly requires it except for xfce4-power-manager,
but other collatoral deps lead back to xfce-session.)
I'm going to build some images without it and can start filing bugs on
anything that comes up.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:22 a.m.
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote:
deserved. Just today I made a minor fix to systemd git to deal
nicely
with PK-less systems.
Right now, I get:
$ reboot
Failed to issue method call: The name org.freedesktop.PolicyKit1 was not
provided by any .service files
Must be root.
Which is fine except that I don't want to see the message. :) Does your fix
handle this or should I bug report?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:26 a.m.
1;3401;0cOn Fri, 09.11.12 12:22, Matthew Miller (mattdm(a)fedoraproject.org) wrote:
On Fri, Nov 09, 2012 at 05:43:17PM +0100, Lennart Poettering wrote:
> deserved. Just today I made a minor fix to systemd git to deal nicely
> with PK-less systems.
Right now, I get:
$ reboot
Failed to issue method call: The name org.freedesktop.PolicyKit1 was not
provided by any .service files
Must be root.
Which is fine except that I don't want to see the message. :) Does your fix
handle this or should I bug report?
Yes, that's the one that should be fixed with this:
http://cgit.freedesktop.org/systemd/systemd/patch/?id=bece1f5215b4ff147e0...
Would probably make sense to test things with this applied as it should
solve most (but probably not all) issues related to PK-less systems.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:33 p.m.
Matthew Miller wrote:
Apparently the new version of polkit brings in javascript. The js
package
is 6.5MB. I think anything that uses polkit will depend on it -- can we
remove it from core?
Of course, the real question is why the heck PolicyKit needs a Turing-
complete rule language (which also forced everyone to port their existing
rules) when the previously-used simple INI-style pkla rule format did the
job just fine!
Kevin Kofler
7:45 p.m.
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote:
Of course, the real question is why the heck PolicyKit needs a
Turing-
complete rule language (which also forced everyone to port their existing
rules) when the previously-used simple INI-style pkla rule format did the
job just fine!
Since policykit was designed from the begining to support multiple
authorities, it does seems like it might have been nicer to continue to
support the ini-style local authority and add the js one as an extra option.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:26 a.m.
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote:
Matthew Miller wrote:
> Apparently the new version of polkit brings in javascript. The js package
> is 6.5MB. I think anything that uses polkit will depend on it -- can we
> remove it from core?
Of course, the real question is why the heck PolicyKit needs a Turing-
complete rule language (which also forced everyone to port their existing
rules) when the previously-used simple INI-style pkla rule format did the
job just fine!
And Unix groups worked OK before that (and still do for the majority
of purposes).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
9:37 a.m.
On Saturday, November 10, 2012 09:26:26 AM Richard W.M. Jones wrote:
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote:
> Matthew Miller wrote:
> > Apparently the new version of polkit brings in javascript. The js
> > package
> > is 6.5MB. I think anything that uses polkit will depend on it -- can we
> > remove it from core?
>
> Of course, the real question is why the heck PolicyKit needs a Turing-
> complete rule language (which also forced everyone to port their existing
> rules) when the previously-used simple INI-style pkla rule format did the
> job just fine!
And Unix groups worked OK before that (and still do for the majority
of purposes).
Another problem is how would we do SCAP configuration checks when the language
will allow 20 different ways to do the same thing? We might be able to do a
SHA256 has of the js. Which means you've completely lost any ability to modify
the behaviour. In an ini file, we could pick out the lines that were important
and check them only allowing other settings we don't care about to change.
Additionally, access control decisions should be audited. There are no
libaudit bindings for javascript.
-Steve
10:31 a.m.
On Mon, Nov 12, 2012 at 10:37:54AM -0500, Steve Grubb wrote:
> > Of course, the real question is why the heck PolicyKit
needs a Turing-
> > complete rule language (which also forced everyone to port their
> > existing rules) when the previously-used simple INI-style pkla rule
> > format did the job just fine!
Another problem is how would we do SCAP configuration checks when the language
will allow 20 different ways to do the same thing? We might be able to do a
SHA256 has of the js. Which means you've completely lost any ability to modify
the behaviour. In an ini file, we could pick out the lines that were important
and check them only allowing other settings we don't care about to change.
Additionally, access control decisions should be audited. There are no
libaudit bindings for javascript.
I'm very sympathetic to these concerns, but this is the way the upstream
package has gone. How do we reconcile that?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
7:10 p.m.
On Sat, 10.11.12 09:26, Richard W.M. Jones (rjones(a)redhat.com) wrote:
On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote:
> Matthew Miller wrote:
> > Apparently the new version of polkit brings in javascript. The js package
> > is 6.5MB. I think anything that uses polkit will depend on it -- can we
> > remove it from core?
>
> Of course, the real question is why the heck PolicyKit needs a Turing-
> complete rule language (which also forced everyone to port their existing
> rules) when the previously-used simple INI-style pkla rule format did the
> job just fine!
And Unix groups worked OK before that (and still do for the majority
of purposes).
OK, I'll bite. So: Did they really?
If you want to allow a user to execute a specific privileged operation
once (let's say format a USB stick), and you grant him group membership
for that, then he can drop a SETGID binary for that group somewhere and
will have the permission forever. Effectively, you can never take group
membership away. Also, creating individual groups for all the various
privileged operations we have simply doesn't scale.
So, PK's usecase is a valid and an important one. You cannot replace
that by Unix groups.
Making PK uninstallable hence really is not about removing something
that was generally not necessary. It is simply about removing something
that is not necessary in the specific usecase of a server setup where no
local unprivileged users exist that might need to execute privileged
operations interactively.
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:34 p.m.
On Thu, 2012-11-15 at 02:10 +0100, Lennart Poettering wrote:
On Sat, 10.11.12 09:26, Richard W.M. Jones (rjones(a)redhat.com)
wrote:
> On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote:
> > Matthew Miller wrote:
> > > Apparently the new version of polkit brings in javascript. The js package
> > > is 6.5MB. I think anything that uses polkit will depend on it -- can we
> > > remove it from core?
> >
> > Of course, the real question is why the heck PolicyKit needs a Turing-
> > complete rule language (which also forced everyone to port their existing
> > rules) when the previously-used simple INI-style pkla rule format did the
> > job just fine!
>
> And Unix groups worked OK before that (and still do for the majority
> of purposes).
OK, I'll bite. So: Did they really?
If you want to allow a user to execute a specific privileged operation
once (let's say format a USB stick), and you grant him group membership
for that, then he can drop a SETGID binary for that group somewhere and
will have the permission forever. Effectively, you can never take group
membership away.
Not saying that groups are always the best option, but I am always
amused by this permanent group membership.
Makes it sound like nobody invented mounting homes with the nosuid mount
option and that admins haven't yet discovered "find -perm" if indeed
there is a file system where users are allowed to drop sgid set
binaries ...
Also, creating individual groups for all the various
privileged operations we have simply doesn't scale.
This is a better argument.
So, PK's usecase is a valid and an important one. You cannot
replace
that by Unix groups.
You might say that it would be difficult or inconvenient, but it can be
replaced if you really want to.
Whether it would make sense to try is a different story ...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9:14 a.m.
On Wed, Nov 14, 2012 at 08:34:00PM -0500, Simo Sorce wrote:
> Also, creating individual groups for all the various
> privileged operations we have simply doesn't scale.
This is a better argument.
> So, PK's usecase is a valid and an important one. You cannot replace
> that by Unix groups.
Which is why it would be nice for it to at least have the option for a
small, simple key-pair authority configuration format.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:27 p.m.
On Sat, 2012-11-10 at 02:33 +0100, Kevin Kofler wrote:
Matthew Miller wrote:
> Apparently the new version of polkit brings in javascript. The js package
> is 6.5MB. I think anything that uses polkit will depend on it -- can we
> remove it from core?
Of course, the real question is why the heck PolicyKit needs a Turing-
complete rule language (which also forced everyone to port their existing
rules) when the previously-used simple INI-style pkla rule format did the
job just fine!
So that more complex rules-parsing can be done instead of hardcoded
rules. For example, when creating a new WiFi network, NetworkManager
could pass along the security options, network details, even the user
that requested creating it. Administrator-written rules can factor all
those details into the decision whether to allow/deny, which the
existing static rules simply cannot do.
Whether or not JS should be a *hard* dependency of PolicyKit, I don't
know. But the feature is valuable, so don't dismiss it out-of-hand.
Dan
1 p.m.
On Monday, November 12, 2012 12:27:52 PM Dan Williams wrote:
On Sat, 2012-11-10 at 02:33 +0100, Kevin Kofler wrote:
> Matthew Miller wrote:
> > Apparently the new version of polkit brings in javascript. The js
> > package
> > is 6.5MB. I think anything that uses polkit will depend on it -- can we
> > remove it from core?
>
> Of course, the real question is why the heck PolicyKit needs a Turing-
> complete rule language (which also forced everyone to port their existing
> rules) when the previously-used simple INI-style pkla rule format did the
> job just fine!
So that more complex rules-parsing can be done instead of hardcoded
rules. For example, when creating a new WiFi network, NetworkManager
could pass along the security options, network details, even the user
that requested creating it. Administrator-written rules can factor all
those details into the decision whether to allow/deny, which the
existing static rules simply cannot do.
except that most admins will never be able to do this. The only people that
get any flexibility are people who manage their own system. Everyone else
likely has some compliance issues and they have to be verifiably in
configuration. What will happen is the generic js file will be SHA256 hashed and
we'll check the file's hash in SCAP and report the system as out of
configuration.
IOW, anyone running any sizeable operation just lost any flexibility.
Whether or not JS should be a *hard* dependency of PolicyKit, I
don't
know. But the feature is valuable, so don't dismiss it out-of-hand.
I think its a bad idea to have too much flexibility for access control systems.
They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG
or any other standard, you have to be able to demonstrate you are in the
approved config. No one can write a test that can tell if the rules really are
sound. So, what will happen is one set will be chosen for better or worse, it
will be SHA256 hashed. And no one can change anything in it without being out
of compliance.
The benefit of the name=value setup is that we can pick out the things that
matter and skip everything else which truly gives flexibility when needing to
demonstrate compliance.
-Steve
3:24 a.m.
On 11/12/2012 08:00 PM, Steve Grubb wrote:
except that most admins will never be able to do this. The only
people that
get any flexibility are people who manage their own system. Everyone else
likely has some compliance issues and they have to be verifiably in
configuration. What will happen is the generic js file will be SHA256 hashed and
we'll check the file's hash in SCAP and report the system as out of
configuration.
This isn't completely sufficient—you also have to make sure that there
isn't another Javascript snippet which overrides the operation of the
valid script.
--
Florian Weimer / Red Hat Product Security Team
4:50 a.m.
Hi Steve,
On 12.11.2012 21:00, Steve Grubb wrote:
I think its a bad idea to have too much flexibility for access control systems.
They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG
or any other standard, you have to be able to demonstrate you are in the
approved config. No one can write a test that can tell if the rules really are
sound. So, what will happen is one set will be chosen for better or worse, it
will be SHA256 hashed. And no one can change anything in it without being out
of compliance.
The benefit of the name=value setup is that we can pick out the things that
matter and skip everything else which truly gives flexibility when needing to
demonstrate compliance.
My question is: Whether be acceptable the required compliance analysis
to be performed on rules written in simplified rule language like
Datalog instead of imperative scripted evaluation in some future version
of polkit ... ?
(It seems to me that e.g. Datalog is good enough both as flexibility and
static analysis (symbolic evaluation), furthermore IMO declarative rules
are less error prone for sysadmins than scripting)
Kind Regards,
Alek
8:37 a.m.
On Tuesday, November 13, 2012 12:50:11 PM Alek Paunov wrote:
Hi Steve,
On 12.11.2012 21:00, Steve Grubb wrote:
> I think its a bad idea to have too much flexibility for access control
> systems. They have to be verifiable. If you have to comply to PCI-DSS or
> the DISA STIG or any other standard, you have to be able to demonstrate
> you are in the approved config. No one can write a test that can tell if
> the rules really are sound. So, what will happen is one set will be
> chosen for better or worse, it will be SHA256 hashed. And no one can
> change anything in it without being out of compliance.
>
> The benefit of the name=value setup is that we can pick out the things
> that
> matter and skip everything else which truly gives flexibility when needing
> to demonstrate compliance.
My question is: Whether be acceptable the required compliance analysis
to be performed on rules written in simplified rule language like
Datalog instead of imperative scripted evaluation in some future version
of polkit ... ?
The standard that everyone is embracing for compliance checking is called
SCAP. Parts of it are also being looked at by the IETF for standardization,
too. I did a presentation on SCAP for the aqueduct project here:
https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech-
talk.pdf
XCCDF represents the policy that you wish to enforce. It is abstract in that
it does not know exactly what file to access or how to perform the check. That
is the job of OVAL, which is concrete in that it has the exact tests and knows
which file to look at.
The OVAL language has a number of checking mechanisms:
http://oval.mitre.org/language/version5.10.1/OVAL_Language_Specification_...
For anything with name=value, we normally use the textfilecontent54 which we
can define a regex to pick out the items of interest. However, with a language,
you have multiple ways of expressing the same idea. for example,
if (foo() > 500)
and
uid = foo();
if (uid > 500)
and
start = 500;
uid = foo();
if (uid > start)
do the same thing. Then throw in comments and indentation and it you have lots
of possibilities. This is also not considering whether the code actually meets
the intent or allows unintended functionality (exploits).
The only thing I can think of, using what's currently available in SCAP is to
use filehash58 and call it a day. This has the drawback of notifying the admin
that the hash doesn't match instead of a useful, actionable, message. They
will be left wondering why the hash doesn't match and what they can do to fix
it.
This is not going to help security. This should be a lesson to anyone wanting
to adopt a languge for system configuration and policy decision.
(It seems to me that e.g. Datalog is good enough both as flexibility
and
static analysis (symbolic evaluation), furthermore IMO declarative rules
are less error prone for sysadmins than scripting)
Do you have a reference for it? I would almost think that you would want to
specify system access rights in a Formal Language which supports the notion of
proofs if anything like this were done. In that event, standards work would
have to be done in preparation for this. I sit on the OVAL editorial Board, so
I could raise the issue to the Board. But javascript for access control policy
is a train wreck for anyone needing to demonstrate compliance.
-Steve
9:26 a.m.
On Tuesday, November 13, 2012 09:37:07 AM Steve Grubb wrote:
For anything with name=value, we normally use the textfilecontent54
which we
can define a regex to pick out the items of interest. However, with a
language, you have multiple ways of expressing the same idea. for example,
if (foo() > 500)
and
uid = foo();
if (uid > 500)
and
start = 500;
uid = foo();
if (uid > start)
do the same thing. Then throw in comments and indentation and it you have
lots of possibilities. This is also not considering whether the code
actually meets the intent or allows unintended functionality (exploits).
The only thing I can think of, using what's currently available in SCAP is
to use filehash58 and call it a day. This has the drawback of notifying the
admin that the hash doesn't match instead of a useful, actionable, message.
They will be left wondering why the hash doesn't match and what they can do
to fix it.
And then if the javascript was found to have a vulnerability in it and it got
fixed or perhaps updated to allow smartcard functionality or something...now
the hash doesn't match. The old vulnerable hash will be forever encoded into
guidance with almost no way to get a standards body to change it.
With name = value, the vulnerability would likely be in the compiled code and
the compliance check would pass. In this case the settings are verifiably
correct because the config file is not changed and part of the compliance check
usually involves running the OVAL content the Red Hat security response team
generates which checks the rpm version.
-Steve
This is not going to help security. This should be a lesson to
anyone
wanting to adopt a languge for system configuration and policy decision.
9:40 a.m.
On Tue, Nov 13, 2012 at 10:26:28AM -0500, Steve Grubb wrote:
With name = value, the vulnerability would likely be in the compiled
code
and the compliance check would pass. In this case the settings are
verifiably correct because the config file is not changed and part of the
compliance check usually involves running the OVAL content the Red Hat
security response team generates which checks the rpm version.
This discussion seems significantly beyond "remove polkit from core". I had
seen the announcement about Javascript in Polkit and kinda shrugged -- not
my ideal as a sysadmin, but, I thought, whatever.
The concerns you raise go beyond the preferences of sysadmins (who, I think
as a rule prefer key-value config files to complex ones). Of course, Fedora
isn't (at least, not right now) targetted at the high-security situations
you describe, but our major downstream consumer sure is. What (if anything)
should Fedora do here? What are our options?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:23 a.m.
On Tue, Nov 13, 2012 at 4:40 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
The concerns you raise go beyond the preferences of sysadmins (who, I
think
as a rule prefer key-value config files to complex ones). Of course, Fedora
isn't (at least, not right now) targetted at the high-security situations
you describe, but our major downstream consumer sure is. What (if anything)
should Fedora do here? What are our options?
So, talking about specific actions...
I have recently had to search all existing polkit policies. This is
no longer possible to automate because various packages ship the
JavaScript policy, so I had to review those by hand. It seems that
(perhaps with the exception of polkit itself) any use of JavaScript
could be converted into the old format, which remains supported.
So, as soon I find some free time (probably next week), I intend to
ask FPC to prohibit using JavaScript if the functionality can be
represented in the old .pkla, and to prepare patches to convert the 6
JS-using packages.
Mirek
1:07 p.m.
----- Original Message -----
So, talking about specific actions...
I have recently had to search all existing polkit policies. This is
no longer possible to automate because various packages ship the
JavaScript policy, so I had to review those by hand. It seems that
(perhaps with the exception of polkit itself) any use of JavaScript
could be converted into the old format, which remains supported.
So, as soon I find some free time (probably next week), I intend to
ask FPC to prohibit using JavaScript if the functionality can be
represented in the old .pkla, and to prepare patches to convert the 6
JS-using packages.
Not sure where you got that information. pkla files are not supported anymore.
So, converting JavaScript rules to pkla syntax won't do any good. What is worthwhile
doing though, is to review all existing packages that ship such rules, and stop them from
doing that, if possible. JavaScript rules are only meant for admin use, no OS-provided
package should install them. We only look in /usr/share to allow for the possibility of
site-local configuration that is distributed in packages.
A concrete action that we are going to take is to split the polkit daemon into its own
subpackage. Then minimal / certifiable installs can contain clients that are using the
polkit libraries, without pulling in the daemon. Polkit clients are already expected to
handle this situation and fall back to allow only uid 0. All of this is documented in
http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html
Matthias
1:32 p.m.
On Tue, Nov 13, 2012 at 02:07:53PM -0500, Matthias Clasen wrote:
A concrete action that we are going to take is to split the polkit
daemon
into its own subpackage. Then minimal / certifiable installs can contain
clients that are using the polkit libraries, without pulling in the
daemon. Polkit clients are already expected to handle this situation and
fall back to allow only uid 0. All of this is documented in
So, is it fair to say that this allows the choice of:
* auditable but with root-only access
* configurable policy that doesn't meet the requirements for some secure
enterprise uses
?
I'm not going to spend a lot of time to oppose that, but I will note that
it's sad to lose the middle ground provided by key-value configuration, when
that covers a lot of cases.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
1:32 p.m.
On Tuesday, November 13, 2012 02:07:53 PM Matthias Clasen wrote:
----- Original Message -----
> So, talking about specific actions...
>
> I have recently had to search all existing polkit policies. This is
> no longer possible to automate because various packages ship the
> JavaScript policy, so I had to review those by hand. It seems that
> (perhaps with the exception of polkit itself) any use of JavaScript
> could be converted into the old format, which remains supported.
>
> So, as soon I find some free time (probably next week), I intend to
> ask FPC to prohibit using JavaScript if the functionality can be
> represented in the old .pkla, and to prepare patches to convert the 6
> JS-using packages.
Not sure where you got that information. pkla files are not supported
anymore.
So, converting JavaScript rules to pkla syntax won't do any good. What is
worthwhile doing though, is to review all existing packages that ship such
rules, and stop them from doing that, if possible. JavaScript rules are
only meant for admin use, no OS-provided package should install them. We
only look in /usr/share to allow for the possibility of site-local
configuration that is distributed in packages.
Turning system configuration into a scriptable language is like going back in
time to the 70's and early 80's where you modified the source to have a
different behavior. Remember Basic programs where if you wanted it to do
something new, you change your copy so its better that the one people were
sharing?
It was decided a long time ago that its better to just have a parser that
looks for the things that people would commonly like to change. This way, you
have some assurance that the main binary has some integrity and you didn't
make some kind of typo that opens access for the world.
As a matter of fact, the better way to do this is via some kind of daemon that
keeps all this information in one giant database. This way its possible to
audit any change to the database and know who did it, what they changed, and
what the old and new values are. This level of service was asked for by
government agencies. We pointed to the sshd config file and said its impossible.
I canplace a watch on the file and I can tell you who changed it and I can tell
you when they changed it, but I cannot tell you what in it changed.
This is the direction I'd rather see the OS go instead of going back to what
amounts to changing the source code. We need to improve the verifiablity rather
than the flexibility.
A concrete action that we are going to take is to split the polkit
daemon
into its own subpackage. Then minimal / certifiable installs can contain
clients that are using the polkit libraries, without pulling in the daemon.
Polkit clients are already expected to handle this situation and fall back
to allow only uid 0. All of this is documented in
http://www.freedesktop.org/software/polkit/docs/latest/polkit-apps.html
We have security configurations for desktop systems. This proposal fixes the
minimal install issue but does not address the compliance issue.
-Steve
http://en.wikipedia.org/wiki/Configuration_file
1:46 p.m.
On Tue, Nov 13, 2012 at 02:32:28PM -0500, Steve Grubb wrote:
It was decided a long time ago that its better to just have a parser
that
looks for the things that people would commonly like to change. This way,
you have some assurance that the main binary has some integrity and you
didn't make some kind of typo that opens access for the world.
It occurs to me this is the exact _opposite_ of the change from init scripts
to systemd service files.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:47 p.m.
Steve Grubb (sgrubb(a)redhat.com) said:
> So, converting JavaScript rules to pkla syntax won't do any
good. What is
> worthwhile doing though, is to review all existing packages that ship such
> rules, and stop them from doing that, if possible. JavaScript rules are
> only meant for admin use, no OS-provided package should install them. We
> only look in /usr/share to allow for the possibility of site-local
> configuration that is distributed in packages.
Turning system configuration into a scriptable language is like going back in
time to the 70's and early 80's where you modified the source to have a
different behavior. Remember Basic programs where if you wanted it to do
something new, you change your copy so its better that the one people were
sharing?
It was decided a long time ago that its better to just have a parser that
looks for the things that people would commonly like to change. This way, you
have some assurance that the main binary has some integrity and you didn't
make some kind of typo that opens access for the world.
Given the move of most system configuration at a large scale to things
such as puppet and chef, I suspect that this argument has already lost in
the marketplace. Obviously, we should still support more locked down
configurations for the sites that need it, but programmatic application
of system configuration is likely to stay.
At least in the puppet/chef/etc cases you can tell when the system has
fallen out of the config, but other than a diff/hash you're not going to be
able to programmatically determine what it being out of configuration means
for the system operation itself.
Bill
3:10 p.m.
On Tue, Nov 13, 2012 at 03:47:25PM -0500, Bill Nottingham wrote:
Given the move of most system configuration at a large scale to
things
such as puppet and chef, I suspect that this argument has already lost in
the marketplace. Obviously, we should still support more locked down
configurations for the sites that need it, but programmatic application
of system configuration is likely to stay.
At least in the puppet/chef/etc cases you can tell when the system has
fallen out of the config, but other than a diff/hash you're not going to be
able to programmatically determine what it being out of configuration means
for the system operation itself.
Doesn't this make things _worse_ for puppet and chef and friends? When using
those systems, it's nice to do the programmatic config and that level, and
have easily-tweaked key value (or single value per file!) configuration.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:17 a.m.
Le mardi 13 novembre 2012 à 16:10 -0500, Matthew Miller a écrit :
On Tue, Nov 13, 2012 at 03:47:25PM -0500, Bill Nottingham wrote:
> Given the move of most system configuration at a large scale to things
> such as puppet and chef, I suspect that this argument has already lost in
> the marketplace. Obviously, we should still support more locked down
> configurations for the sites that need it, but programmatic application
> of system configuration is likely to stay.
>
> At least in the puppet/chef/etc cases you can tell when the system has
> fallen out of the config, but other than a diff/hash you're not going to be
> able to programmatically determine what it being out of configuration means
> for the system operation itself.
Doesn't this make things _worse_ for puppet and chef and friends? When using
those systems, it's nice to do the programmatic config and that level, and
have easily-tweaked key value (or single value per file!) configuration.
No, you can just use a template and hide it behind the proper
abstraction.
it make things worse for stuff like augeas however.
--
Michael Scherer
2:09 p.m.
On Tue, Nov 13, 2012 at 8:07 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
----- Original Message -----
> So, talking about specific actions...
>
> I have recently had to search all existing polkit policies. This is
> no longer possible to automate because various packages ship the
> JavaScript policy, so I had to review those by hand. It seems that
> (perhaps with the exception of polkit itself) any use of JavaScript
> could be converted into the old format, which remains supported.
>
> So, as soon I find some free time (probably next week), I intend to
> ask FPC to prohibit using JavaScript if the functionality can be
> represented in the old .pkla, and to prepare patches to convert the 6
> JS-using packages.
Not sure where you got that information. pkla files are not supported anymore.
My mistake - I meant the *.policy files in /usr/share/polkit-1/actions
, which definitely do affect system behavior.
What is worthwhile doing though, is to review all existing packages
that ship such rules, and stop them from doing that, if possible. JavaScript rules are
only meant for admin use, no OS-provided package should install them.
Good, so we seem to agree on this part. That would resolve my
concerns (ability to ability to analyze configuration shipped in
Fedora by a program), but not Steve's (ability to analyze admin's
customized configuration).
A concrete action that we are going to take is to split the polkit
daemon into its own subpackage. Then minimal / certifiable installs can contain clients
that are using the polkit libraries, without pulling in the daemon. Polkit clients are
already expected to handle this situation and fall back to allow only uid 0. All of this
is documented in
Hm, I don't like that much. Having two completely separate
authorization code paths in many software components makes it very
likely that the less frequently used code path will be buggy at least
in some components.
Mirek
2:44 p.m.
Miloslav Trmač (mitr(a)volny.cz) said:
> A concrete action that we are going to take is to split the
polkit daemon into its own subpackage. Then minimal / certifiable installs can contain
clients that are using the polkit libraries, without pulling in the daemon. Polkit clients
are already expected to handle this situation and fall back to allow only uid 0. All of
this is documented in
Hm, I don't like that much. Having two completely separate
authorization code paths in many software components makes it very
likely that the less frequently used code path will be buggy at least
in some components.
Applications are already supposed to be able to cope with polkitd not
being present; it's not really an authorization code path as much as
it is just good defensive coding.
Bill
3:27 p.m.
Miloslav Trmač wrote:
I have recently had to search all existing polkit policies. This is
no longer possible to automate because various packages ship the
JavaScript policy, so I had to review those by hand. It seems that
(perhaps with the exception of polkit itself) any use of JavaScript
could be converted into the old format, which remains supported.
Actually, we were told multiple times that .pkla is no longer supported and
no longer works and that we all have to use JavaScript .rules in F18+.
Kevin Kofler
9:50 p.m.
----- Original Message -----
Miloslav Trmač wrote:
> I have recently had to search all existing polkit policies. This
> is
> no longer possible to automate because various packages ship the
> JavaScript policy, so I had to review those by hand. It seems that
> (perhaps with the exception of polkit itself) any use of JavaScript
> could be converted into the old format, which remains supported.
Actually, we were told multiple times that .pkla is no longer
supported and
no longer works and that we all have to use JavaScript .rules in
F18+.
Yes, this was a misunderstanding. What is still supported is the .policy files containing
the default policy. And that is very good, since such policy files are installed by pretty
much every package that uses polkit, while .pkla files were only used by very few
packages.
11:53 p.m.
On 11/13/2012 09:50 PM, Matthias Clasen wrote:
Yes, this was a misunderstanding. What is still supported is the .policy files containing
the default policy. And that is very good, since such policy files are installed by pretty
much every package that uses polkit, while .pkla files were only used by very few
packages.
Wait. So the .pkla file I wrote to allow my run virt-manager as my
normal user is going to stop working, and I'm going to have to write the
replacement in JavaScript?
Let's just say I'm struggling to find the words ...
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================
1:07 a.m.
On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher <arequipeno(a)gmail.com> wrote:
On 11/13/2012 09:50 PM, Matthias Clasen wrote:
>
> Yes, this was a misunderstanding. What is still supported is the .policy
files containing the default policy. And that is very good, since such
policy files are installed by pretty much every package that uses polkit,
while .pkla files were only used by very few packages.
>
Wait. So the .pkla file I wrote to allow my run virt-manager as my
normal user is going to stop working, and I'm going to have to write the
replacement in JavaScript?
Let's just say I'm struggling to find the words ...
In F18 yes.
http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html
http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html
Tim
8:26 a.m.
Once upon a time, tim.lauridsen(a)gmail.com <tim.lauridsen(a)gmail.com> said:
On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher
<arequipeno(a)gmail.com> wrote:
> Wait. So the .pkla file I wrote to allow my run virt-manager as my
> normal user is going to stop working, and I'm going to have to write the
> replacement in JavaScript?
>
> Let's just say I'm struggling to find the words ...
In F18 yes.
http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html
http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html
Great - let's take something that people are using, remove that
functionality, and not announce it!
This is not cool; it represents one of my biggest frustrations with a
bunch of the "new and improved" ways of doing things. You track down
how to do something, it works for a few releases, and then it doesn't
anymore with no notice.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:44 a.m.
On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams <cmadams(a)hiwaay.net> wrote:
Great - let's take something that people are using, remove that
functionality, and not announce it!
This is not cool; it represents one of my biggest frustrations with a
bunch of the "new and improved" ways of doing things. You track down
how to do something, it works for a few releases, and then it doesn't
anymore with no notice.
I don't mind this much in isolation— and to some extent its
unavoidable if there is to be progress.
I also have the experience and impression that Fedora often dismisses
use cases in the 'long tail' as things that "power users" can get by
twiddling some opaque config file or registry entry or hacking some
bit of code— this happens more often the closer you get to the
desktop, but believe its a culture which permeates the project more
generally than that. In isolation this too would be occasionally
frustrating but finite in baddness.
The combination of the two— that anything non-stock is subject to
constant and often undocumented breakage _and_ that many non
nearly-universal use cases are too non-mainstream to consider
supportable stock features really diminishes the value I receive from
using a distribution at all.
More on the subject— in this brave new polkit JS world, when an
administrator is considering upgrading their Fedora (or even some
packages), what tools will they have to validate that their local JS
actually works at all much less produces the desired behavior? I
don't see any tools or documentation to facilitate that. It seems
to me that adding a bunch of unsound programmatic configuration which
can't reasonably be used by the end users due the overhead of keeping
up regular fedora churn, especially absent good validation tools, is
not a productive change relative to just baking in the additional
logic and exposing it via basic configuration switches.
1:33 p.m.
On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote:
On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams
<cmadams(a)hiwaay.net> wrote:
> Great - let's take something that people are using, remove that
> functionality, and not announce it!
>
> This is not cool; it represents one of my biggest frustrations with a
> bunch of the "new and improved" ways of doing things. You track down
> how to do something, it works for a few releases, and then it doesn't
> anymore with no notice.
I don't mind this much in isolation— and to some extent its
unavoidable if there is to be progress.
I also have the experience and impression that Fedora often dismisses
use cases in the 'long tail' as things that "power users" can get by
twiddling some opaque config file or registry entry or hacking some
bit of code— this happens more often the closer you get to the
desktop, but believe its a culture which permeates the project more
generally than that. In isolation this too would be occasionally
frustrating but finite in baddness.
The combination of the two— that anything non-stock is subject to
constant and often undocumented breakage _and_ that many non
nearly-universal use cases are too non-mainstream to consider
supportable stock features really diminishes the value I receive from
using a distribution at all.
I was trying yesterday to formulate a question for the people running
for FESCo along these lines; also what they thought about:
https://news.ycombinator.com/item?id=4772133
However I wasn't able to formulate a snappy and non-carping question
in time for the deadline.
Still, I do believe it's something that FESCo (those elected and those
standing for election) ought to address.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
1:34 p.m.
On 11/14/2012 07:33 PM, Richard W.M. Jones wrote:
On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote:
> On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams <cmadams(a)hiwaay.net> wrote:
>> Great - let's take something that people are using, remove that
>> functionality, and not announce it!
>>
>> This is not cool; it represents one of my biggest frustrations with a
>> bunch of the "new and improved" ways of doing things. You track down
>> how to do something, it works for a few releases, and then it doesn't
>> anymore with no notice.
> I don't mind this much in isolation— and to some extent its
> unavoidable if there is to be progress.
>
> I also have the experience and impression that Fedora often dismisses
> use cases in the 'long tail' as things that "power users" can get
by
> twiddling some opaque config file or registry entry or hacking some
> bit of code— this happens more often the closer you get to the
> desktop, but believe its a culture which permeates the project more
> generally than that. In isolation this too would be occasionally
> frustrating but finite in baddness.
>
> The combination of the two— that anything non-stock is subject to
> constant and often undocumented breakage _and_ that many non
> nearly-universal use cases are too non-mainstream to consider
> supportable stock features really diminishes the value I receive from
> using a distribution at all.
I was trying yesterday to formulate a question for the people running
for FESCo along these lines; also what they thought about:
https://news.ycombinator.com/item?id=4772133
However I wasn't able to formulate a snappy and non-carping question
in time for the deadline.
Still, I do believe it's something that FESCo (those elected and those
standing for election) ought to address.
Why are other OS and upstream decision/discussion int their regard fesco
problem?
Should not their focus be first and foremost on our own distribution and
our own OS?
JBG
3:43 a.m.
On Wed, Nov 14, 2012 at 07:34:22PM +0000, "Jóhann B. Guðmundsson" wrote:
On 11/14/2012 07:33 PM, Richard W.M. Jones wrote:
>On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote:
>>On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams <cmadams(a)hiwaay.net> wrote:
>>>Great - let's take something that people are using, remove that
>>>functionality, and not announce it!
>>>
>>>This is not cool; it represents one of my biggest frustrations with a
>>>bunch of the "new and improved" ways of doing things. You track
down
>>>how to do something, it works for a few releases, and then it doesn't
>>>anymore with no notice.
>>I don't mind this much in isolation— and to some extent its
>>unavoidable if there is to be progress.
>>
>>I also have the experience and impression that Fedora often dismisses
>>use cases in the 'long tail' as things that "power users" can
get by
>>twiddling some opaque config file or registry entry or hacking some
>>bit of code— this happens more often the closer you get to the
>>desktop, but believe its a culture which permeates the project more
>>generally than that. In isolation this too would be occasionally
>>frustrating but finite in baddness.
>>
>>The combination of the two— that anything non-stock is subject to
>>constant and often undocumented breakage _and_ that many non
>>nearly-universal use cases are too non-mainstream to consider
>>supportable stock features really diminishes the value I receive from
>>using a distribution at all.
>I was trying yesterday to formulate a question for the people running
>for FESCo along these lines; also what they thought about:
>
>https://news.ycombinator.com/item?id=4772133
>
>However I wasn't able to formulate a snappy and non-carping question
>in time for the deadline.
>
>Still, I do believe it's something that FESCo (those elected and those
>standing for election) ought to address.
Why are other OS and upstream decision/discussion int their regard
fesco problem?
Should not their focus be first and foremost on our own distribution
and our own OS?
No. I think it's important to behave well with the larger free
software community, and that includes other Linux distros and *BSD.
From a purely selfish point of view, it leads to larger numbers of
users testing our software in more configurations [different
platforms, with and without different combinations of software
installed], which is more likely to reveal bugs.
Anyway, I'd like to hear what FESCo members have to say about this,
because it would strongly influence who I would vote for.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
9:19 a.m.
New subject: fedora elections questions [Re: remove polkit from core?]
On Thu, Nov 15, 2012 at 09:43:41AM +0000, Richard W.M. Jones wrote:
Anyway, I'd like to hear what FESCo members have to say about
this,
because it would strongly influence who I would vote for.
Yeah, I too came up with a couple of questions I'd like to add to
https://fedoraproject.org/wiki/F19_elections_questionnaire, but the question
collection period is over.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:07 a.m.
New subject: fedora elections questions [Re: remove polkit from core?]
On Thu, Nov 15, 2012 at 9:19 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Thu, Nov 15, 2012 at 09:43:41AM +0000, Richard W.M. Jones wrote:
> Anyway, I'd like to hear what FESCo members have to say about this,
> because it would strongly influence who I would vote for.
Yeah, I too came up with a couple of questions I'd like to add to
https://fedoraproject.org/wiki/F19_elections_questionnaire, but the question
collection period is over.
There will be a townhall where you or a proxy can ask them as well.
John
9:47 a.m.
On Wednesday, November 14, 2012 08:07:25 AM tim.lauridsen(a)gmail.com wrote:
On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher
<arequipeno(a)gmail.com> wrote:
> On 11/13/2012 09:50 PM, Matthias Clasen wrote:
> > Yes, this was a misunderstanding. What is still supported is the .policy
>
> files containing the default policy. And that is very good, since such
> policy files are installed by pretty much every package that uses polkit,
> while .pkla files were only used by very few packages.
>
>
> Wait. So the .pkla file I wrote to allow my run virt-manager as my
> normal user is going to stop working, and I'm going to have to write the
> replacement in JavaScript?
>
> Let's just say I'm struggling to find the words ...
In F18 yes.
http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html
This blog misses the most important property about security settings...they
have to be auditable through automation. If you have 10,000 systems and need
to know your security posture, you have to be able to check them through
automation.
If the javascript had a file over in /etc that it read configuration things
from, then we are OK. But if we have to go check the code itself, there is a
problem.
-Steve
10:37 a.m.
New subject: PKLA --> JavaScript
On 11/14/2012 01:07 AM, tim.lauridsen(a)gmail.com wrote:
I've just reviewed those pages, and it's certainly not obvious to me
how I would go about "porting" a PKLA file.
[libvirt Management Access]
Identity=unix-group:wheel
Action=org.libvirt.unix.manage
ResultAny=no
ResultInactive=no
ResultActive=yes
The latter page, in particular, reads like something written for an
audience of developers, rather than system administrators. I'm sure
that I can figure it out in time, but this seems like a terrible burden
to put on system administrators, particularly those who are (sometimes
proudly) averse to anything that smacks of "programming".
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================
11 a.m.
New subject: PKLA --> JavaScript
On Thu, Nov 15, 2012 at 5:37 PM, Ian Pilcher <arequipeno(a)gmail.com> wrote:
I've just reviewed those pages, and it's certainly not
obvious to me
how I would go about "porting" a PKLA file.
[libvirt Management Access]
Identity=unix-group:wheel
Action=org.libvirt.unix.manage
ResultAny=no
ResultInactive=no
ResultActive=yes
The latter page, in particular, reads like something written for an
audience of developers, rather than system administrators. I'm sure
that I can figure it out in time, but this seems like a terrible burden
to put on system administrators, particularly those who are (sometimes
proudly) averse to anything that smacks of "programming".
the .rules file should look like this: and go into *
/usr/share/polkit-1/rules.d/ *
polkit.addRule(function(action, subject) {
if (action.id == "org.libvirt.unix.manage" &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;;
}
});
11:09 a.m.
New subject: PKLA --> JavaScript
Once upon a time, tim.lauridsen(a)gmail.com <tim.lauridsen(a)gmail.com> said:
the .rules file should look like this: and go into *
/usr/share/polkit-1/rules.d/ *
System-local config belongs in /etc, not /usr. Is there a corresponding
/etc path for rules?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:10 a.m.
New subject: PKLA --> JavaScript
On Thu, Nov 15, 2012 at 11:09:07AM -0600, Chris Adams wrote:
Once upon a time, tim.lauridsen(a)gmail.com
<tim.lauridsen(a)gmail.com> said:
> the .rules file should look like this: and go into *
> /usr/share/polkit-1/rules.d/ *
System-local config belongs in /etc, not /usr. Is there a corresponding
/etc path for rules?
We went through this with the old version too:
http://lists.freedesktop.org/archives/polkit-devel/2009-November/000258.html
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
noon
New subject: PKLA --> JavaScript
On Thu, Nov 15, 2012 at 6:10 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Thu, Nov 15, 2012 at 11:09:07AM -0600, Chris Adams wrote:
> Once upon a time, tim.lauridsen(a)gmail.com <tim.lauridsen(a)gmail.com> said:
> > the .rules file should look like this: and go into *
> > /usr/share/polkit-1/rules.d/ *
> System-local config belongs in /etc, not /usr. Is there a corresponding
> /etc path for rules?
We went through this with the old version too:
http://lists.freedesktop.org/archives/polkit-devel/2009-November/000258.html
Yeah, except this time there is also /etc/polkit-1/rules.d, so call of
the alarm :)
Mirek
11:06 a.m.
New subject: PKLA --> JavaScript
On Thu, Nov 15, 2012 at 5:37 PM, Ian Pilcher <arequipeno(a)gmail.com> wrote:
[...] but this seems like a terrible burden
to put on system administrators, particularly those who are (sometimes
proudly) averse to anything that smacks of "programming".
Thus are by definition not system administrators. There are not
supposed to be software developers but being able to deal with simple
code (shell scripts?!) is part of a sysadmins jobs.
So the solution would be "fire him and hire a new one".
11:09 a.m.
New subject: PKLA --> JavaScript
On Thu, Nov 15, 2012 at 06:06:44PM +0100, drago01 wrote:
Thus are by definition not system administrators. There are not
supposed to be software developers but being able to deal with simple
code (shell scripts?!) is part of a sysadmins jobs.
So the solution would be "fire him and hire a new one".
Or better yet! Fire all the Linux people and hire much cheaper admins for an
OS where you can configure everything by clicking on stuff.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:12 a.m.
New subject: PKLA --> JavaScript
On Thu, 15 Nov 2012 12:09:53 -0500
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Thu, Nov 15, 2012 at 06:06:44PM +0100, drago01 wrote:
> Thus are by definition not system administrators. There are not
> supposed to be software developers but being able to deal with
> simple code (shell scripts?!) is part of a sysadmins jobs.
> So the solution would be "fire him and hire a new one".
Or better yet! Fire all the Linux people and hire much cheaper
admins for an OS where you can configure everything by clicking on
stuff.
but you need 10 times as many clickies.
6:24 a.m.
On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote:
Wait. So the .pkla file I wrote to allow my run virt-manager as my
normal user is going to stop working, and I'm going to have to write the
replacement in JavaScript?
This particular case is the primary one I've seen for people actually
writing their own policy. I think maybe we should make a Unix group for it
and make that the default. (But I don't think that solves the problem.)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11 a.m.
On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote:
> Wait. So the .pkla file I wrote to allow my run virt-manager as my
> normal user is going to stop working, and I'm going to have to write the
> replacement in JavaScript?
This particular case is the primary one I've seen for people actually
writing their own policy. I think maybe we should make a Unix group for it
and make that the default. (But I don't think that solves the problem.)
If David is unwilling to just resurrect the old .pkla parser, one
option for "solving" the problem might be writing a piece of code that
would provide compatibility with the .pkla files.
This could be (the only) JS config snippet parsing the files directly
if the JS environment allowed file system access, or alternatively a
generator run before starting polkit to generate a large JS config
representing the contents of .pkla files.
Anyone interested in implementing it?
Mirek
1:44 p.m.
----- Original Message -----
On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller
If David is unwilling to just resurrect the old .pkla parser, one
option for "solving" the problem might be writing a piece of code
that
would provide compatibility with the .pkla files.
This could be (the only) JS config snippet parsing the files directly
if the JS environment allowed file system access, or alternatively a
generator run before starting polkit to generate a large JS config
representing the contents of .pkla files.
Anyone interested in implementing it?
The .pkla syntax wasn't particularly appealing or expressive, and there was only a
handful of packages using it. I don't really think it is particularly worth reviving.
If a declarative syntax is needed, I suggest that the security team simply picks their
favourite language, and then implements a single js rule that calls out to a commandline
utility implementing that language. Checking compliance should be very simple then - just
check that the single single rule is the one you put in place.
10:26 a.m.
On 2012-11-09 18:27, Matthew Miller wrote:
The js package is 6.5MB.
BTW I suppose that could be significantly reduced by linking /usr/bin/js
with the dynamic libmozjs instead of the static one generated during the
build. It seems to take something more than just the attached patch though.
2:41 a.m.
On 11/10/2012 05:26 PM, Ville Skyttä wrote:
On 2012-11-09 18:27, Matthew Miller wrote:
> The js package is 6.5MB.
BTW I suppose that could be significantly reduced by linking /usr/bin/js
with the dynamic libmozjs instead of the static one generated during the
build. It seems to take something more than just the attached patch though.
Most interpreters deliberately do this because non-PIC code is
significantly faster than PIC code, especially on architectures without
IP-relative addressing. These days, it may be possible to recover some
of the lost performance by tweaking ELF symbol visibility or
amalgamation builds (that is, stuffing everything in a single C file;
-flto could perhaps provide an equivalent).
--
Florian Weimer / Red Hat Product Security Team
12:03 p.m.
On Mon, Nov 12, 2012 at 09:41:22AM +0100, Florian Weimer wrote:
On 11/10/2012 05:26 PM, Ville Skyttä wrote:
>On 2012-11-09 18:27, Matthew Miller wrote:
>>The js package is 6.5MB.
>
>BTW I suppose that could be significantly reduced by linking /usr/bin/js
>with the dynamic libmozjs instead of the static one generated during the
>build. It seems to take something more than just the attached patch though.
Most interpreters deliberately do this because non-PIC code is
significantly faster than PIC code, especially on architectures
without IP-relative addressing.
Two notes: tis might be the default case upstream but it's not normal
behaviour in what we package for Fedora:
$ ldd `which perl`|grep libperl
libperl.so => /usr/lib64/perl5/CORE/libperl.so (0x00000034d1e00000)
$ ldd `which python`|grep libpython
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00000034da000000)
$ ldd `which ruby`|grep libruby
libruby.so.1.9 => /lib64/libruby.so.1.9 (0x00000034bca00000)
ajax (IIRC) analyzed the speed increase of non-PIC code when he worked on
this:
https://fedoraproject.org/wiki/User:Tibbs/Text_Relocation_Guidelines?rd=U...
He found a "small performance benefit", not "significantly faster"
performance. He also made the case that non-PIC code has negative
performance characteristics that are weighed against the gains.
-Toshio
4172
days inactive
4179
days old
55 comments
23 participants
participants (23)
-
Alek Paunov -
Bill Nottingham -
Chris Adams -
Dan Williams -
drago01 -
Florian Weimer -
Frank Murphy -
Gregory Maxwell -
Ian Pilcher -
inode0 -
Jóhann B. Guðmundsson -
Kevin Kofler -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
Michael Scherer -
Miloslav Trmač -
Richard W.M. Jones -
Simo Sorce -
Steve Grubb -
Tim Lauridsen -
Toshio Kuratomi -
Ville Skyttä