FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-01-2010, 10:47 PM
Adam Williamson
 
Default Next privilege escalation policy draft

Hi again, folks. Here is another draft of the privilege escalation
policy. This is the sixth draft (second to this list). Changes: one of
Kevin Kofler's queries alerted me to the fact that somehow all the
changes between draft 1 and draft 2 were lost from drafts 3 onwards,
d'oh They are restored, which addresses some points people raised
here that were previously raised and addressed on test list. I also
tried to clarify some more that the planned system whereby there'll be
an 'administrative users' group that the first account gets added to
automatically and to which other users can be added manually is OK, and
clarified the point KK misunderstood about what constitutes a 'policy
escalation mechanism'.

again, comments are welcome! This is probably going to FESco next week,
not tomorrow, apparently they have a heavy schedule tomorrow.

https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-02-2010, 09:33 AM
Tomas Mraz
 
Default Next privilege escalation policy draft

On Mon, 2010-02-01 at 15:47 -0800, Adam Williamson wrote:
> Hi again, folks. Here is another draft of the privilege escalation
> policy. This is the sixth draft (second to this list). Changes: one of
> Kevin Kofler's queries alerted me to the fact that somehow all the
> changes between draft 1 and draft 2 were lost from drafts 3 onwards,
> d'oh They are restored, which addresses some points people raised
> here that were previously raised and addressed on test list. I also
> tried to clarify some more that the planned system whereby there'll be
> an 'administrative users' group that the first account gets added to
> automatically and to which other users can be added manually is OK, and
> clarified the point KK misunderstood about what constitutes a 'policy
> escalation mechanism'.
>
> again, comments are welcome! This is probably going to FESco next week,
> not tomorrow, apparently they have a heavy schedule tomorrow.
>
> https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy

What about all networking setup changes? Especially establishing a VPN
connection can be used to tunnel all traffic through a rogue VPN server
thus enabling attacker to monitor all the network traffic. The same
holds for enabling WLAN interfaces if they are currently disabled.

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-02-2010, 06:07 PM
Adam Williamson
 
Default Next privilege escalation policy draft

On Tue, 2010-02-02 at 11:33 +0100, Tomas Mraz wrote:

> > again, comments are welcome! This is probably going to FESco next week,
> > not tomorrow, apparently they have a heavy schedule tomorrow.
> >
> > https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy
>
> What about all networking setup changes? Especially establishing a VPN
> connection can be used to tunnel all traffic through a rogue VPN server
> thus enabling attacker to monitor all the network traffic. The same
> holds for enabling WLAN interfaces if they are currently disabled.

Right, good point, and it's not covered specifically under any existing
point because you could do all of that without editing a config file or
directly manipulating network traffic, if someone stuffed up the
permissions model of ifconfig or NetworkManager.

Will add. Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-04-2010, 07:14 PM
Adam Jackson
 
Default Next privilege escalation policy draft

On Mon, 2010-02-01 at 15:47 -0800, Adam Williamson wrote:
> Hi again, folks. Here is another draft of the privilege escalation
> policy. This is the sixth draft (second to this list). Changes: one of
> Kevin Kofler's queries alerted me to the fact that somehow all the
> changes between draft 1 and draft 2 were lost from drafts 3 onwards,
> d'oh They are restored, which addresses some points people raised
> here that were previously raised and addressed on test list. I also
> tried to clarify some more that the planned system whereby there'll be
> an 'administrative users' group that the first account gets added to
> automatically and to which other users can be added manually is OK, and
> clarified the point KK misunderstood about what constitutes a 'policy
> escalation mechanism'.
>
> again, comments are welcome! This is probably going to FESco next week,
> not tomorrow, apparently they have a heavy schedule tomorrow.
>
> https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy

Thank you for taking this on. Apologies for not looking this over
sooner, I've been away from email for the last two weeks.

Some nitpicking:

- "Read or write directly to or from system memory" is, technically,
something every process does. "Device or kernel memory" might be closer
to the spirit of the law?

- Declaring "Read from system logs containing any information about user
activities" to be a privileged action, means that who(1) and last(1)
break, since utmp and wtmp are typically - intentionally - world
readable. /var/log/ConsoleKit/history similarly. I think this entire
rule is mostly subsumed under the "directly access or modify a file they
would usually be denied rights to" clause, though we'd probably also
want to define what kinds of log information are sensitive and what
aren't in that case, and enforce world-readability to match.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-04-2010, 10:39 PM
Adam Williamson
 
Default Next privilege escalation policy draft

On Thu, 2010-02-04 at 15:14 -0500, Adam Jackson wrote:

> Some nitpicking:
>
> - "Read or write directly to or from system memory" is, technically,
> something every process does. "Device or kernel memory" might be closer
> to the spirit of the law?

Yeah, that's one people have said is somewhat amorphous. It's important
to note that I'm using the word 'directly' in the policy to mean 'allow
to user to specifically control the process' - i.e. it's not just about
an application the user is using reading memory, it's more about
(apologies for my 1980s terminology :>) not letting the user PEEK and
POKE.

> - Declaring "Read from system logs containing any information about user
> activities" to be a privileged action, means that who(1) and last(1)
> break, since utmp and wtmp are typically - intentionally - world
> readable. /var/log/ConsoleKit/history similarly. I think this entire
> rule is mostly subsumed under the "directly access or modify a file they
> would usually be denied rights to" clause, though we'd probably also
> want to define what kinds of log information are sensitive and what
> aren't in that case, and enforce world-readability to match.

I don't understand much about utmp and wtmp, but if appropriate they
could be specifically excepted from the policy. Ditto the ConsoleKit
history. What's the rationale for these being world-readable?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-05-2010, 12:02 AM
Björn Persson
 
Default Next privilege escalation policy draft

Adam Jackson wrote:
> - "Read or write directly to or from system memory" is, technically,
> something every process does. "Device or kernel memory" might be closer
> to the spirit of the law?

That wouldn't cover other users' processes. How about "memory that is not
allocated to the users' own processes"?

Björn Persson
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-05-2010, 07:21 PM
Adam Jackson
 
Default Next privilege escalation policy draft

On Thu, 2010-02-04 at 15:39 -0800, Adam Williamson wrote:
> On Thu, 2010-02-04 at 15:14 -0500, Adam Jackson wrote:
> > - Declaring "Read from system logs containing any information about user
> > activities" to be a privileged action, means that who(1) and last(1)
> > break, since utmp and wtmp are typically - intentionally - world
> > readable. /var/log/ConsoleKit/history similarly. I think this entire
> > rule is mostly subsumed under the "directly access or modify a file they
> > would usually be denied rights to" clause, though we'd probably also
> > want to define what kinds of log information are sensitive and what
> > aren't in that case, and enforce world-readability to match.
>
> I don't understand much about utmp and wtmp, but if appropriate they
> could be specifically excepted from the policy. Ditto the ConsoleKit
> history. What's the rationale for these being world-readable?

Unix used to be a multiuser OS, apparently.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-05-2010, 11:52 PM
Adam Williamson
 
Default Next privilege escalation policy draft

On Fri, 2010-02-05 at 15:21 -0500, Adam Jackson wrote:

> > I don't understand much about utmp and wtmp, but if appropriate they
> > could be specifically excepted from the policy. Ditto the ConsoleKit
> > history. What's the rationale for these being world-readable?
>
> Unix used to be a multiuser OS, apparently.

As I said, I don't understand much about them. i.e., I don't know what
they're used for. i.e., flippant answers aren't terribly helpful. =) I
am terribly sorry for only having shown up within the last decade or so,
I fully appreciate this makes me a terrible Johnny-come-lately...

I can guess from the commands referenced that one or both record recent
login actions, yes?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-08-2010, 01:47 PM
Adam Jackson
 
Default Next privilege escalation policy draft

On Fri, 2010-02-05 at 16:52 -0800, Adam Williamson wrote:

> As I said, I don't understand much about them. i.e., I don't know what
> they're used for. i.e., flippant answers aren't terribly helpful. =) I
> am terribly sorry for only having shown up within the last decade or so,
> I fully appreciate this makes me a terrible Johnny-come-lately...
>
> I can guess from the commands referenced that one or both record recent
> login actions, yes?

utmp is the list of currently logged in users, along with what device
they're logged in on, where they're logged in from (if it's a telnet/ssh
kind of connection), how long they've been on, etc. wtmp is much the
same except it's a historical record and contains login and logoff
times. It also tends to contain entries for pseudousers for events like
reboots, power loss, etc.

So utmp isn't especially privileged information; if you could get into
the machine to read it at all, you could just as easily do "ps auwx |
grep sh" or "ls -l /dev/pts" and get a pretty good idea of who's logged
in. It's in /var/run, not /var/log, but the difference between log file
and scoreboard is kind of academic in my mind. And there's a legitimate
usage as well; it lets you know whether someone is available for talk(1)
or write(1) messages, or whether you need to warn people before
rebooting the machine.

wtmp might be considered "sensitive" by paranoid admin types. If you
haven't rebooted in a while, you may be running an old kernel with a
security hole; but uname would tell you that just as well. If you see
someone always ssh's in from the same machine, you might infer that
they've got some kind of magic ssh key that lets them log in from that
machine passwordless, so you'd attack that one next; but again, netstat
while they're logged in would tell you what machine they're coming from.

I tend to believe that if trivially observable behaviour is
security-sensitive, you have two problems.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org